A Techopedia munkatársai, 2016. november 30
Elvihető: Eric Kavanagh, házigazda, Dr. Robin Bloor, Dez Blanchfield és az IDERA Bullett Manale megvitatja a kérdéseket és arról, hogy hatékonyságuk milyen messzemenő hatással lehet.
Jelenleg nincs bejelentkezve. Kérjük, jelentkezzen be vagy jelentkezzen be a videó megtekintéséhez.
Eric Kavanagh: Hölgyeim és uraim, üdvözlet és üdvözlet újra. Szerdán négy óra van a keleti idő, és manapság ez azt jelenti, hogy itt az ideje a Hot Technologies-nek! Igen valóban. Ma jó dolgokról beszélünk. Természetesen én vagyok a házigazda, Eric Kavanagh. A mai show címe: „A hatékony elemzés kulcsa: gyorsan visszatérő lekérdezések.” Így van, emberek, mindannyian gyorsan akarunk. Ki nem akar gyorsan? Van egy dia rólad, és valóban rólam. Találj fel a Twitteren, @eric_kavanagh. Örülök, hogy kapcsolatba léphetek veled, és beszélgethetek a közösségi médiában. Nagyon szórakoztató lehet, csak ne beszélj a politikáról.
Az év forró. Idén különböző analitikai kérdésekről beszéltünk, és a mai egyik téma valójában csak a munka elvégzésének központi eleme. Emlékszem, valószínűleg öt vagy hat évvel ezelőtt hallottam először, hogy valaki a „beszéljen az Ön adataival” kifejezést használja, és bár ez kissé sajtosnak hangzik, a lényeg az, hogy ha nincs iteratív tapasztalata a az adatai, ha nem tudják gyorsan módosítani a lekérdezéseket, új lekérdezéseket küldeni, gyorsan megkapni a válaszokat, akkor nem beszélgetnek az adatokkal, és az egész analitikai folyamat csonka. Ez nem jó.
Ha beszélgetni kezdi az adatokkal, ez azt jelenti, hogy képes oda-vissza mozogni, és véleményem szerint ez az, amikor megismeri a betekintést. Mivel nagyon ritkán először jön ki a tökéletes lekérdezés. Ha nem az elemző Mozart vagy - és biztos vagyok benne, hogy ez a személy ott van -, akkor töltenie kell egy kis időt a módosítással, valamilyen dimenzió hozzáadásával, és megpróbálja finomítani, hogy mit keresel .
Mert ismét ezek nem olyan hatalmas nehézségekkel bíró környezetek, amelyekkel az elemzés világában foglalkozunk; nagyon nehézkes környezetekkel, nagyon bonyolult és többdimenziós környezetekkel állunk szemben. Tehát a mai internetes közvetítés célja az, hogy beszéljünk arról, hogyan tegyük lehetővé az ilyen jellegű iteratív interakciót az adataival.
Három előadónk van. Természetesen a Hot Technologies-ben, szemben a Briefing Room-val, két elemzőnk van; mindegyik először megadja a vetést, aztán a vendég bejön, előadást tart, és van egyfajta kerekasztalunk. És te, közönségünk, nagy szerepet játszhat ebben. Kérjük, ne légy félénk; bármikor küldje el kérdéseit. Ha lehetséges, használja a Kérdések és válaszok panelt, különben a csevegőpanel rendben van; Megpróbálom mindkettőt figyelni a show alatt. És ezeket rögzítjük, tehát ha hiányzik valami, vagy meg akarja osztani kollégáival, térjen vissza később. Feladjuk őket a Techopedia.com webhelyre és az InsideAnalysis.com webhelyre.
És ezzel bevonom az okos embereket. Átadom Dr. Robin Bloornak. Hadd adjam neki a kulcsokat, cserélje ki az elõadót, és odamenne. Robin, vedd el.
Robin Bloor: Oké. Köszönöm az intro-t. Körülbelül másfél hónappal ezelőtt beszélgettem egy fejlesztővel, aki valójában DBA. Valójában nem DBA - egy DBA volt egy adott társaságban, és ő volt az egyetlen személy, aki ténylegesen rá tudta készíteni a lekérdezéseket. De belefáradt, hogy ezt csinálja, mert valójában nagyon meglehetősen okos fejlesztő. Szóval elment.
És minden hónapban néhány napot kell tennie értük, mert nem találtak senkit, aki helyére lépne, és nem tudják, mit tudnak az adatbázis csinálni, vagy hogy hogyan kell hangolni. És erre gondoltam, és tudod, valójában nem volt informatikai osztályuk, de ez a srác támogatást nyújtott nekik. Valójában a DBA munkáját végezte az idő nagy részében.
A kifinomult adatbázisok - az Oracle, SQL Server, DB2 -, az összes nagy és drága adatbázis esetén az adatbázis hangolása nehéz feladat. Ez egy biztonságos munka is. És valóban az az oka annak, hogy ezt mondjuk, hogy ez egy változó táj. Kicsit átmegyek ezen. Tudod, relációs adatbázisok - általában a nagy kép az, hogy a relációs adatbázisok továbbra is uralják a népszerűséget. Valószínűleg sokáig dominálnak. Igen, vannak más adatbázisok is, amelyeknél hosszabb a működési idő, de tudod, amikor valójában megnézed, mi folyik odakint, az Oracle végzi a legtöbbet, a Microsoft SQL Server a második, és különféle dolgok történnek a felhőben, amelyek kihívást jelenthet. Ők a játék nagy óriásai. És ezek az adatbázisok, amelyeket mind az OLTP, mind az adattárház-terhelésekhez egyaránt használhat. Az alternatívákat általában elsősorban analitikus környezetben használják, majd általában az adatok határozzák meg, hogy miért választottuk ezt inkább, mint a relációs. Leginkább az emberek nem.
A vállalatok hajlamosak egységesíteni egyetlen adatbázist. Nemrég találkoztam olyan társasággal, amely több mint 5000 Oracle példányt tartalmazott. És én valaki, az a személy, akivel azzal a társasággal beszéltem, valami kérdést tettem nekik a DBA-kkal kapcsolatban. Azt mondták, hogy körülbelül 10 DBA-ja van, és körülbelül 30 adatbázist őriztek. És a többi, az Oracle-t csak végleges rendszerként használták. Nagyon kevés hangsúlyt fektettek az azokat használó alkalmazások adataira. De ez csak valami meghökkent - 5000 Oracle példány.
És egyébként Oracle birtoklicencük volt. Nos, tudod, természetesen a vállalati licenc. De vannak más adatbázisuk is, mert tudod, hogy az alkalmazások néha az előnyben részesített adatbázisokkal érkeznek. Nem volt olyan, mintha csak az Oracle lenne. És érdemes megemlíteni, hogy sem a Hadoop, sem a Spark nem valójában adatbázis, és hosszú idő múlva elsajátítják azt, amit adatbázis-szabálynak gondolok. Természetesen jó az adatkapcsolatokhoz.
A DBA tevékenységekkel - Bullett valószínűleg szörnyen sokkal többet mond erről, mint én -, de én csak átvágom rajtam. Tudod, ezekre gondolok általában a DBA. Telepítik, konfigurálják, frissítik, licenckezelést végeznek. Sok ETL és replikációs munkát végeznek úgy vagy úgy. Tárolást és kapacitástervezést végeznek. Hibaelhárítást végeznek, vagy a hibaelhárítási csoport tagjai. A teljesítményfigyelés és hangolás a tevékenységük nagy részét képezi, de az összes többi cucc, nem kicsi, tudod. Biztonság, felelősek a biztonsági mentésért és a helyreállításért. Be kell vonni őket a szoftvertesztelő rendszerekbe, és be lehet vonni az adatok életciklusába.
Teljesítmény. Amikor régen ilyen fickók voltam. Amikor adatbázisokat futtattam és hangoltam, így értettem meg, érted? Van a CPU, és manapság így vagy úgy, a CPU általában nagyjából tétlen, mert a másik kettő egyikének lenne, vagy a th-nak. Nos, a másik szűk keresztmetszet valójában okozza a problémát. Memória, dobás és széttöredezettség, vagy lemez vagy lemez I / O telítettség, néha hálózati fölött, ha a hálózat több csomópontjában fut, és valószínűleg valószínűleg valamilyen reteszelés is zajlik.
De ez volt a világ, amint láttam. Nemrég átnéztem az Oracle-t és az Oracle-ban található hangolási paraméterek számát. Ez több mint 300 volt. Tudod, és ha valóban erre gondolsz, egy DBA-nak, aki valóban tudja, mit csinál, van valamilyen ötlete, hogy miért zavarja valaha is ezeket. Tehát ez egy bonyolult munka, tudod, és ez bonyolultabb.
Tudod, most már vannak CPU-k, de megvan … a CPU-k már léteztek, GPU-k a CPU-n vagy FPGA-kkal a CPU-n. Tehát van egyfajta keresztezés, ami valóban történik a CPU-n. A processzorok régen többmagossá váltak; valójában már nem hangoltam az adatbázisokat, amikor ez történt. Fogalmam sincs, hogy mi a különbség valójában, miután most gondolkodtam rajta.
Tudod, hogy a 3D Xpoint és az IBM PCM egy extra memóriarétegként jelent meg, és rendelkezünk SSD-kkel, de tudod, ezek helyettesítik a forgó rozsda helyét. Az SSD-k sebessége azonban változhat. Olyan sokkal rendelkezik párhuzamos hozzáféréssel, és ez hihetetlenül gyorsan megy - a RAM sebességéhez közel. És megvan az összes párhuzamos hardveres architektúra.
És ez minden, tudod, a költségek csökkennek, ami nagyon szép dolog, de ez mindent megtesz - tudod, ha elkészíti az adatbázis következő kiadását, és elkezdi azt végrehajtani a gépeken, akár néhány ez valójában elvesztette a bélérzetet, amely az adatok viselkedésével kapcsolatban merülhet fel, mert a késések nagyon-nagyon különböznek egymástól. És itt, tudod, négy réteg van, nem pedig három réteg tároló.
Adatbázis-kérdések. Kapsz adatbázis-entrópiát - a példányok elterjedése nagyon gyakori. Az adatbázisokat szekrényekként használják, és ez volt az, amit valójában adtam. Nagyon kevés adatbázis működik önhangolással, és azok, amelyek állítják, hogy önhangoltak, valójában nem olyan jók, tudod. De a másik dolog az, hogy nagyon kevés adatbázis van megfelelően beállítva. Kemény munka, mivel képes egyensúlyba hozni a munkaterhelést. Úgy értem, amikor egy adatbázisra gondolunk, hogy mit csinál egy adatbázis egy 24 órás időszak alatt, a munkaterhelés nagyon-nagyon eltérő lehet. Az adatbázisnak különösen igaz adattárháznak kell lennie.
Ezért a hangolást, amely nem triviális kérdés, tudod, mert éppen azon paraméterek hangolása van, amelyek egy adott időponttól kezdve a teljes munkaterhelésnek megfelelnek. Alapvetően nehéz munka. Az SQL-t különösen az SQL JOIN-okhoz kell hangolni. Ezek rendkívül, erőforrás-igényesek, tudod. És ha az adatbázisban megvalósultak a nézetek, akkor őszintén szólva, meg kell vizsgálnunk azok használatát, mert ezek mindent hihetetlenül gyorsabban hajtanak végre. És ehhez szükség van valakire, aki megérti a munkaterhelést, megérti az SQL forgalmat és így tovább és így tovább.
És a legtöbb vállalat nagyon kevés DBA-t alkalmaz - nagyon drága. Ismertem meglehetősen nagy cégeket, mint például három srác, tudod, hatalmas számú példány. Valójában sokba kerülnek, a bonyolultság szempontjából nehéz feladat. Szerszámokra van szükségük.
És azt hiszem, ennyit kell mondanom. Ó igen. Adjuk át Dez-nek, nézzük meg, mit mondott Dez.
Dez Blanchfield: Köszönöm, Robin. Ez egy hatalmas téma. Fogom tartani azokat a dolgokat, amelyek szerintem ténylegesen mindennapi kihívások, amelyekkel szembesülünk. Mivel nézzünk szembe, van egy teljes könyvtár, amely erről a témáról írt. Ki nem ment egy műszaki könyvesboltba, és megtalálta a falak és a falak közt az éppen az adatbázis-teljesítmény és az adatbázis hangolása, valamint a monitorozás témájára írt könyvek falát. És néha ez egy nagyszerű módszer az idő megölésére.
Általános téma: teljesítménykérdezések beszerzése. A szervezetnek számos olyan része van, amely izgatja ezt a témát - a végfelhasználói szinten, tapasztalatom szerint, tudod, hogy az emberek csak a teljesítményt tapasztalják meg, hogy a dolgok lassúak. A forgó kerekek eltartanak egy ideig, hogy visszatérjenek a kérdések. A spektrum ellentétes végén van olyan infrastrukturális és hálózati és tárolótechnikai embere, akit az adatbázis-szakemberek vernek fel, mert a dolgok nem olyan jól futnak, mint amire számítanak. És ez egy nagyon széles spektrum, tapasztalataim szerint, azok a dolgok, amelyek befolyásolhatják az életünket abban a spektrumban.
Ha fizikailag felfelé gondolkodik, akkor tudod, csak a számítógépes helyről. Van memóriája, tudod, RAM, ha úgy tetszik - lemezterület, hálózat és az összes bit. Ebben a térben azt a gondolatot tárolja, hogy mondjuk azt mondjuk, hogy jobb, ha nyers lemezt vagy JBOD-t használunk, és csak, tudod, a lehető leggyorsabban emelkedik fel a lemez, és hagyja, hogy a adatbázis rendezi az adatvédelmi réteget. Mások nagy rajongói a RAID-nek, az olcsó lemezek redundáns sorozatának, és különböző vallási tapasztalatokkal rendelkeznek a RAID 0, 1, 3, néha 5 és 6 különféle típusú csíkozással vagy replikációval a lemezen, ha a merevlemez meghibásodik. Még tárolási és műszaki szinten is vannak olyan emberek, akiknek eltérő véleményük van és tapasztalataik vannak a teljesítmény körül, a tárolás típusainál.
Legyen szó közvetlenül csatlakoztatott lemezekről és magukról a szerverekről, vagy akár száloptikai csatornán keresztül van-e valamilyen formátumú tárolóhálózattal összekötve, függetlenül attól, hogy valamelyik szerverről telepítve van-e az iSCSI-n keresztül, vagy például Ethernet-et. És még mielőtt valóban eljutna az adatbázis-réteghez, ahol, tudod, az a fajta dolog, amit magától értetődőnek tekintünk - tudod, csak fenntartod ezt, amint Eric felvázolta, tudod, hogy mi az úgynevezett beszélgetés az Ön adataival . Csak az, hogy képes azonosítani a mintákat és az értelmes mintákat, amelyekről azt gondoljuk, hogy elkezdhetünk belemerülni és kereshetünk teljesítményproblémákat.
És ez egy nagyon széles téma, tehát két területre merülnék, ahol tapasztalataim szerint a befektetett idő, energia és erőfeszítés jó eredményt hoz. Tehát hadd csak gyorsan ugorjak át az elsőre. És csak félig tréfálva kerestem egy képet, amelyben valami csontváz és kívül bőr van, de a Lego blokk valószínűleg a legkevésbé félelmetes. De sok szempontból így képzeltem el és szellemileg ábrázolom azt a kihívást, amelyen néha szembe kell néznünk az azokat támogató elemző platformokkal és adatbázisokkal. És ez az, hogy valójában csak Ön, mint fogyasztó és végfelhasználó, vagy akár fejlesztő, gyakran látja a furnérozott bőrréteget, de valójában az alatti csontváz - ez a kérdés, amelyre összpontosítania kell.
Tudja, ebben az esetben, amikor azon dolgokra gondolunk, amelyek hatással lehetnek az adatbázis teljesítményére és elemzésére az adott nap eredményeként, akkor a teljesítmény elérése, az alapinfrastruktúra és csak az alapinfrastruktúra megfigyelése, és amint egy pillanattal ezelőtt felvázoltam, körül a lemez, a memória és a CPU. És amint azt Dr. Robin Bloor kiemelte, a virtualizáció kihívásai és a zsetonban zajló dolgok, a teljes teljesítmény a központi szintre, valamint a memóriamennyiség, amelyet ma minden egyes chipbe beépítenek. Ezek nagyon technikai kihívások, amelyekkel mindennapi embert meg kell vizsgálni.
A lekérdezés figyelésének tetején tartása. Tudod, a lekérdezések és a lekérdezési sorok figyelésének egyik kihívása például: - Úgy értem, hogy az SQL mint nyelv és az analitikai eszközök körüli adatbázis-eszközök nagyon erősek, és különösen az SQL mint nyelv. De ezzel a hatalommal és egyszerűséggel sok esetben is jön, és ha ez nem egy olyan alkalmazás, amely újra és újra elvégzi ugyanazt a dolgot, egy jó fejlesztő írta és egy jó DBA észlelte, akkor ez valószínűleg legyenek az emberek nem strukturált lekérdezések.
És azzal a probléma, hogy meglehetősen könnyű megtanulni egy kicsit az SQL-t és elkezdeni lekérdezéseket tenni, de ennek eredményeként nem feltétlenül kell minden képessége, tapasztalata és ismerete ahhoz, hogy megtudja, jó vagy rossz az adatbázis elkészítése. Tehát ugyanazon nagy, széles, rossz folyamatos futás csak leteheti az épületet. Érdekes kihívás a kérdésfigyelés tetején tartása.
Csak a válaszidő figyelése, amennyire a platform csinál, és mit szereznek a felhasználók. Ismét tudja, hogy a megfelelő eszközök nélkül ez nem olyasmi, hogy csak intuitív módon nézi a dolgot, és azt gondolja: „Ó, a hálózat lassan működik” vagy „a felhasználói memória nem teljesít jól”, vagy „az indexek rosszul teljesítenek Vagy „puffadnak”.
És akkor, tudod, hogyan jutsz el arra a pontra, ahol - miután észrevetted a problémát - hogyan szét lehet húzni, és szétválaszthatja, és meg tudja oldani a rosszul strukturált kérdések teljes kihívását? És tudod, ez egy ad hoc lekérdezés, amelyet valaki kézzel fut, vagy egy olyan elemző eszköz, amelynek műszerfal elülső része rosszul teljesít, mert rosszul adják fel a kérdéseket, vagy csak egy igazán, igazán rosszul írt kóddarab?
És ezt az iterációs lépést elvégezve, mondta Eric a kezdeti felépítésben, tudod, csak iteratívan megy újra és újra, és finomhangolja ezeket a munkafolyamatokat. Tudod, milyen munkafolyamatokat futok, hogyan futnak, milyen gyakran futnak, milyen kód fut ezek ellen, hol futnak vele szemben a CPU-ban, a memóriában, valamint a lemezen és a hálózaton? Igen, ez csak egy nagyon-nagyon technikai kihívás.
És akkor a nirvana, amelyet az emberek keresnek ezen a világon, miközben elmozdul a történelmi elemzések és a teljesítmény hangolása és a környezettel szembeni riasztás mellett, ami nagyszerű látni, mert a jövőben terveket kaphat rá, ha tudod, miért ment a dolgok lassúvá tegnap reggel kilenc órakor. De ez nem segít neked, és nem segíti a jövőbeni tervét is.
Úgy gondolom, hogy a kapacitástervezés, a méretezés, a méretezés és a hangolás, tehát tudod, úgy gondolom, hogy van egy trend, amelyet most látunk, ahol változás történik nagyon nagy környezetekben, ahol az emberek nagy adatbázis-platformokkal és széles körben elterjedt adatbázis-környezetekkel rendelkeznek. a történelmi riasztástól és a tervezéstől a prediktív riasztásig és a tervezésig, ahol meg akarják tudni, hogy mi történik jelenleg, és képesek lesznek megtervezni a továbblépést. Vagy elfogy a memória, és a következő órában elfogy a memória, és mit tehetünk vele? Milyen kapacitástervezést tehetünk valós időben?
Elnézést. Arra a pontra jut, hogy, tudod, csak az ezen akadályok felfedezésének teljes kihívása akadályozza meg lényegében azt, amit folyékony elemzésnek nevezünk, és ezt normává tesszük a szervezetében. Mint láthatja, ez egy nem triviális kihívás, tudod, csak a mindennapi nagy, mosatlan tömegek számára. És ez még mindig nem triviális kihívás még a technikailag hozzáértő emberek számára is.
Tudod, ha nehéz az egyszerű halandók számára, hogyan tehetjük ezt lehetségesvé? Mert, tudod, ezek többsége olyan dolgok, amelyeket a szokásos felhasználók nem tudnak megoldani, és lehet, hogy vannak speciális adatbázis-mérnökök, adatbázis-fejlesztők, kódfejlesztők, programozók, ám ezek mégis képesek voltak a környezet szétválasztására. El kell távolítaniuk, tudod, olyan kérdésekről, mint például az emberek, akik újrafelhasználják a kódot.
Tudod, az egyik legrosszabb dolog, amelyet ezen a téren láttam az analitikai platformokon az adatbázis-kiszolgáló-infrastruktúra nagyon nagy telepítésein elért teljesítmény-találatok körül, az az, hogy az emberek egy darab kódot vesznek fel, egy SQL-darabokat vagy ellopott eljárást, amit nem végeztek el. Nem írnak, és nem tudják, hogy ez jó vagy rossz kód -, és csak újra felhasználják, mert ez biztosítja számukra a kívánt eredményt. De kiderül, hogy valószínűleg csak valami olyasmit írtak, hogy egy vagy két eredményt kapjunk, például egy jelentést - valaki sietve volt.
Tehát az emberek olyan összetett kódot használnak, amelyet nem írtak, és csak beillesztik egy alkalmazásfejlesztésbe, nem tudva, hogy valójában megbünteti a hátsó végét. Még csak annak ellenőrzése, hogy az előadás találat megfigyelhető, és ahonnan megkeresik a lekérdezéseket, és kimerítik, ez, tudod, mindennapi kihívás.
Alapvető viselkedési dolgok, például adatok előkészítése a teljesítmény érdekében, ahol csak lehetséges. A tapasztalatok csak megtanítanak, mint például az indexek törlése, ha tömeges importálást hajt végre, majd újraindexel, így az indexek nem maradnak fenn, amikor terabyte-os adatot húz be. A megfelelő eszközök nélkül ezt szinte lehetetlen látni, mert nem tudja, hogy az index hammerd.
Az indexek rendszeres optimalizálása 101-es típusú, de mi van, tudod, ha tömeges importálást végez, vagy tudod, ha táblát állít fel a lekérdezésekre, ha valaki nagyon nagy lekérdezést hajt végre? Tudod, hogy ez hatalmas teljesítménylehetőség lehet, és ismét, ha nem figyeli, akkor nincs eszköze annak látására, hogy ilyen történik a háttérben, és nem tudja, hogyan kell kezelni .
A lekérdezések csak a szükséges oszlopok számára korlátozódnak - úgy értem, hogy nagyon alapvetőnek hangzik, de ha nem látja, akkor nem tudja, hogy történik, és akkor csak a háttérben történik, és fáj, rád.
Annak ismerete, mikor és hol használható átmeneti táblák, nagy törlések és frissítések kötegelt. Megint nagyon egyszerű dolgok, de a láthatóság nélkül, az ehhez szükséges eszközök nélkül, csak a háttérben ülnek, és továbbra is bántanak téged, és csak több memóriát vagy CPU-t dobnak egy adatbázis-környezetbe, hogy jobb analitikai platform teljesítményt érjenek el, amikor valóban képesnek kell lennie arra, hogy bemélyítse a részletekbe, mi bánt téged, és foglalkozzon az adott dologgal. És akkor tudod, olyan dolgok, mint például a külföldi kulcskorlátozások, és hogyan találja meg ezt, hogyan is tudja, hogy ez kérdés?
Ezzel levonom a kulcsfontosságú pontom következtetését, vagyis tudod, hogy napi szinten ezeket a problémákat mindenhol látják. És amint az adatbázis-környezetek egyre nagyobbá válnak, egyre szélesebbé válnak, és ahogyan Dr. Robin Bloor kiemelte itt, egyre összetettebb környezeti modelleket kapunk adatbázis-idővel.
És aztán az is, hogy integráljunk az olyan nagy adatplatformokba, mint a Hadoop és a Spark, amelyek egyre inkább megjelennek, és egyre több. Véleményem szerint jobb módszereket és eszközöket kell találnunk e valós idejű platformteljesítmény, elemzés és diagnosztika intelligens végrehajtására. Mert valós időben, valódi pénzt és csalódást okoz a végfelhasználóknak, valamint valódi dollárokat, ha nem kezdjük el hozzájutni az eszközökbe, amelyekbe belemerülünk ezekbe a dolgokba.
És ezzel átadom az IDERA barátainknak, mert azt hiszem, hogy jó történeteik vannak, amelyek elmondják, hogyan tudnánk kezelni ezt a problémát.
Bullett Manale: Jól hangzik. Nagyon köszönöm, és megyek előre, és elindulok a dolgok. Van itt is néhány diája, és hagytam, hogy megyek előre, és ezt előhozom. Ezek közül néhányon gyorsan átjutunk.
Csak azért, hogy némi betekintést nyújtsak, én vagyok az IDERA értékesítési igazgatója. Tehát eléggé rendszeresen beszélünk a DBA-kkal a fájdalmakról és a kihívásokról, amelyek sok esetben sajátosak., a teljesítményfigyelés és az ilyen dolgok nyilvánvalóan. És sokat hallunk ebből a közönségből, és így gondolom, hogy megoszthatom néhány olyan információt, amelyet rendszeresen kapok tőlük, és ennek értelme van. Megnézek néhányat ezek közül, mert nem hiszem, hogy valóban relevánsak lennének a beszélgetésben.
Tudod, itt van saját listám a DBA felelősségeiről - nagyjából hasonlít Robin listájára, és azt hiszem, hogy elég következetes. Azt hiszem, amikor beszélünk egy adatbázis-kezelővel, az mindig így van - tudod, ezekbe a területekbe inkább belemerülnek, mint másokba, és nincs rá rím vagy ok, csak a környezettől függ.
Nagyon szélesebb, sokféle dolgot hallasz, amelyeket az emberek képesek akarnak tenni. És sokszor az emberek, akik ezeket a dolgokat akarják, nem fogják megkérni őket, és bizonyos esetekben elkezdenek fúrni azt, amit igazán kérnek, majd rájönnek, hogy tényleg többet keres. Nagyon több információt akarnak, mint amit eredetileg gondolnának, és amikor elkezdesz fúrni a szerszámot, azt hiszem, itt kezdheti el mondani, hogy beszélgetnek az adatokkal.
És azt hiszem, hogy ez egy igazán érdekes kifejezés, és nagyon sok értelme van annak, hogy azt mondjuk, igen, nos, ha rossz lekérdezésed van, mi az a rossz lekérdezés? Ez egy lekérdezés, amely sok olvasást vagy írást vagy CPU-t igényel? Lehet, hogy sokat fut, tudod, hogy ez, ahogy mondtad, rosszul írt.
Annak meghatározása szempontjából, hogy mi a termékünket, a Diagnostic Manager terméket, számos szempontból láthatjuk, hogy megmutatjuk a DBA-knak, hogy meg tudják valósítani ezt. És ez valóban rugalmas, és azt hiszem, ez az egyik nagy dolog - rendelkeznie kell egy eszközzel, amely segít ezekben a teljesítményproblémákban, mindenki környezete kissé eltér.
És nagyon sok lesz, tudod, szükségletekre és talán még homályos követelményekre is vonatkozik a monitorozás terén, tehát rendelkeznie kell valamivel, amely rugalmas, és működni fog, és képesnek kell lennie arra, hogy megfeleljen a környezetnek, próbálsz kezelni. Tudod, és nagyon sok ilyen példaom van - nem fogom áttekinteni mindegyiket, de szüksége van valamire, amelyet előre-hátra forgathat az egyik darab és a másik között, és ilyen beszéljünk erről, amikor egy kicsit bekerülünk a termékbe, és megmutatjuk neked, és hogy mi is csináljuk.
De a másik dolog, amire gondolok, hogy bármely jó elemző eszköz, tudod, vannak olyan alapvető dolgok, amelyeket valóban keres. Ön nyilvánvalóan elsősorban és nem akarja, hogy egy eszköz, amely saját teljesítményproblémákat okozna a teljesítmény nevében. Amikor azt mondom, hogy díjmentesen gyűjtsük össze az adatokat, nem a költségekről gondolok, tudod, a pénzköltségekről, hanem a költségekről az általános költségek szempontjából és a költségekről az erőforrások mennyiségére vonatkoztatva. a teljesítmény nevében fogják használni. Határozottan akar valamit, ami segít.
Szüksége van valamire, amely képes lesz arra, hogy megkapja a keresett adatokat, amelyek jellemzőek a napi szintű problémákra, és lehet, hogy vannak olyan dolgok, amelyekre nincs szüksége, és amelyeket nem kell megadnia. nem akar, és nincs értelme gyűjteni ezeket az adatokat, ha soha nem fog jelentést készíteni róla, vagy bármilyen igénye lenne az adatok kezelésének megkísérlése körül. Például a teljesítményhez kapcsolódó metaadatok szempontjából.
Tudod, jó példa erre, hogy nem kell figyelmeztetnem, ha az SQL Distributed Transaction Coordinator szolgáltatás nem működik, ha nem akarom, hogy az előbb futjon. Tehát ne figyelmeztessen, ne gyűjtsön ellene adatokat - nincs szükségem erre az információra. Tehát nagyon fontos az a képesség, hogy be- és kikapcsoljuk ezeket a dolgokat.
Az a képesség is, hogy ha egyszer összegyűjti az adatokat, elég gyorsan hozzáférne hozzájuk - nem kell, hogy tudja, futtassa és masszírozza az adatokat, manipulálja az adatokat - képes gyorsan és hatékonyan elkészíteni azokat. És ha egyszer megvan az adatok, akkor nyilvánvalóan nagyon fontos, hogy megértsük azokat.
Most itt, itt, például - például a Diagnostic Manager termékkel, amit ma kicsit megmutatlak neked - az a termék, tudod, szeretném mondani, hogy ez a termék cserélje ki és DBA legyen egy dobozban. A valóság az, hogy bizonyos ismereteket igényel arról, hogy mi a környezet, és mit akar elérni. Nyilvánvalóan fontos, hogy megismerjük maga a DBA szerepét.
Most megpróbálunk segítséget és más módszereket alkalmazni. De ezt nyilvánvalóan el akarja kötni valamilyen típusú tapasztalati szinttel vagy valakivel, akinek van tudása arról, hogy mit kell tennie, miután megkapta az adatokat. És nyilvánvalóan kulcsfontosságú az a képesség, hogy van egy olyan személy, aki felteheti a termékhez megfelelő kérdéseket, és hogy megbeszélje az adatokat. És akkor nyilvánvalóan képes értelmezni az adatokat.
Amint megvan az információm, képes vagyok rájutni a megfelelő emberekhez. Fejlesztőim, a műveleti csapatom - bármi is legyen az, előfordulhat, hogy integrálnom kell más termékeket, és rendelkeznék a horgokkal, hogy ezt megtehessem. Ezek mind valóban fontos dolgok. És akkor természetesen utoljára, de nem utolsósorban, ha többet kell tudnom, hogy képes vagyok erre. Ez azt jelenti, hogy bekapcsolja-e még néhány adatgyűjtést, vagy azt jelenti, hogy csak egy kicsit mélyebben megyünk az adatokba. Reméled, hogy egy eszköz segítségével, amely lesz, tudod, hogy a teljesítményhez hozzájárul, és megszerez minden olyan dolgot, amelyre szükség van ahhoz, hogy válaszoljon ezekre a kérdésekre.
Az egyetlen dolog, amelyet nem tettem ide, és azt gondolom, hogy érdemes megjegyezni, az, hogy szüksége van egy eszközre, amely segít megkülönböztetni a normál és a nem normális eseményeket. És azt hiszem, ez nagy, mert tudod, van egy csomó figyelmeztető termék és dolog, amelyek ott vannak, de ha riasztást kap, és a riasztás hamis riasztás, akkor ez nem jár ; több idő pazarlás, és jobban csökkenti hatékonyságát, mint segíteni fog nekik. Szóval, tudod, ezeket néhány dolgot szem előtt tartanám.
Amikor arról a termékről beszélek, hogy mindezeket az IDERA termékcsaládhoz kötözem, a Diagnostic Manager termékre gondolom, hogy ez valószínűleg a fő jellemzői annak, amit itt beszélünk az adatbázis szempontjából hangolás és teljesítmény és monitorozás és ilyen jellegű dolgok.
Az emberek vállalati szintű monitoringot keresnek; szeretnének hozzáférni és tudni, hogy egy képernyőn tudják, hogy a dolgok úgy működnek, ahogy kellene. Vagy nyilvánvalóan képesek lesznek, ha probléma merül fel, megnézni, hol van a probléma, majd bele tudnak mélyíteni. Azt hiszem, hogy az emberek valódi nagy része az ilyen típusú módszereket keresi, amelyekkel valóban élesen tudod fellépni.
A másik dolog, ami nyilvánvalóan ehhez kapcsolódik, az az, hogy nem tudok csak a jelenben működni, és képesnek kell lennem arra, hogy egy bizonyos időszakon keresztül visszamenjenek, függetlenül attól, hogy rosszul futó lekérdezéseket tekintünk-e, vagy azt jelenti, hogy te tudom, nézve azt a módot, amellyel maga a host virtuális gép viselkedett az erőforrások szempontjából. Mindezek a dolgok, amelyeket képesnek kell lennie, és nem fogsz ott ülni, a nap 24 órájában, a hét minden napján a konzolon bámulva.
Ha nyaralsz, vagy éjszaka közepén van, vagy bármi is legyen, szüksége van valamire, ami képes visszatérni az időbe veled, hogy meg tudja mondani, mi történt a amikor problémánk volt. És ez a megbeszélés szempontjából egyértelműen fontos, hogy ismét hatékonyan és gyorsan meg tudjuk csinálni, és be tudjuk mélyíteni. És azt mondanám, hogy valószínűleg az egyik legfontosabb dolog, amit az emberek keresnek. Mindig az ablakot keresik a múltba, mert ez tényleg im - tudod, nem akarja, hogy ott üljön és várjon, amíg valami megismétlődik.
A lista következő dolga valójában az, hogy visszamegyünk ahhoz, amit korábban beszéltünk, maga a lekérdezés teljesítményével. És néhány különféle példát mutatok be a Diagnostic Manager termékben, hogyan csináljuk ezt, ami természetesen a nap végén sok lehetőséget kínál Önnek a lekérdezések körében annak szempontjából, hogy össze akarsz gyűlni.
Annak szempontjából, hogy érdekli-e olyan kérdéseket, amelyek erőforrás-fájdalmat okoznak, a CPU-fogyasztás vagy az I / O-fogyasztás. Legyen olyan lekérdezés, amely hosszú időt vesz igénybe, vagy olyan lekérdezés, amely általában nem a teljesítmény szempontjából a legrosszabb, de olyan gyakran futhat, hogy önmagában a futás puszta gyakorisága problémát jelenthet. És ennek nyilvánvaló képessége az, hogy idővel észrevehessük a trendeket ezekkel a lekérdezésekkel is.
Sokféle módon meg tudjuk csinálni ezt a terméket, és azt hiszem, hogy ez nyilvánvalóan valódi fontos elem a legtöbb DBA számára. És még akkor is, ha nincs saját belsőleg kifejlesztett alkalmazásuk, örülök, hogy elmehetünk a szoftver gyártójához és azt mondhatjuk: “Hé, tudod mit? Tudod, minden nap délután kettő délután, amikor ez a munka elindul ”, vagy bármi is legyen:„ Ez az alkalmazásod okozza ezt, és meg kellett javítanunk. ”Tehát akkor is, ha nincs teljes ellenőrzés maga a kód felett, még mindig jó tudni, hogy mikor merülnek fel problémák.
És akkor, tudod, a másik rész nyilvánvalóan proaktívabb. Annak képessége, hogy elsőként megismerje, megértse, mikor jelentkezik probléma. Annak érdekében, hogy ne csak az elsőként tudjon meg tudni kijavítani, hanem sok esetben, amikor szüksége van valamire, amely képes automatizálni a választ, sok esetben is. Tehát mondhatja, hogy tudod, ahelyett, hogy e-mailt kapna: „Hé, ezt meg kell javítanod”, ha találkozón vagyok, vagy ha tudod, útban vagy bármi más vagyok Csinálok, nyilvánvalóan nagyon szép, hogy elmondhatom, hogy van valami a helyemben, amely képes lesz arra, hogy ezt automatikusan megválaszolja.
És ha ezzel nem foglalkoznak automatizált módon, akkor legalább tudni kell az elsőként, hogy tudjon lépéseket tenni, vagy kapcsolatba lépni valakivel, aki erre képes. És tehát ezek nyilvánvalóan nagy fontos részek, tudod, ezeknek a problémáknak a típusai, amelyekkel felmerülhetnek a gépek és a példányok, valamint maguk az analitikák megfigyelése szempontjából.
Most már erről beszéltem korábban, ami a dolgok rugalmassága. Nem tudom ezt eléggé hangsúlyozni, mert azt mondhatom, hogy tudod, kívülről, ha van valami, amit nem figyelnek, képesnek kell lennie arra, hogy a termék funkcionalitása hozzá tudja adni ezeket a dolgokat figyelni kell. És a Diagnostic Manager példájának értelmében nyilvánvalóan, tudod, hogy WMI számlálók, számlálók, SQL Server számlálók készíthetnek saját lekérdezéseket.
Akár azt is tudja, ha szeretné, kihúzza az adatokat a vCenter vagy a Hyper-V környezetből, a folyamatban levő szavazás eredményeként, és képes tudni ezt rendszeresen elvégezni, és húzza ki ezeket az adatokat, és képes legyen azokat megnézni. És ismét forgassa egyik helyről a másikra, amikor ezeket az információkat nézi.
Tehát ezek a fajta dolgok, amelyekben azt látom, hogy az emberek azt kérdezik, amikor egy eszközről beszélnek, amely segíteni fog nekik a hangolás és a teljesítmény szempontjából - a termék, amelyet csak egy a második a Diagnostic Manager, és mindent támogat 2000-től egészen 2016-ig. Ez az SQL Serverre vonatkozik, és így felügyeljük a dolgok kezelését. Magukon a példányokon nincs ügynök, amely a példányt figyeli.
Ez az információ kis költséggel történő összegyűjtéséig nyúlik vissza, hogy tudod, nyilvánvalóan megpróbáltuk ezeket az információkat összegyűjteni, és nem is sok erőforrást használunk, ugye? Megpróbáljuk kiaknázni azokat a dolgokat, amelyeket az SQL Server már biztosított nekünk, és jobbá tesszük azokat, legyen az dinamikus kezelési nézetek, kiterjesztett események, vagy bármi más is legyen a gyűjtemény szempontjából. Az a képesség, hogy felhasználjuk ezeket az információkat és javítsuk azokat, az egyik megbízatásunk.
Most, ha gyorsan átnézed ezt a valóságot, nem fogok túl részletesebben átmenni az építészetet, de van egy háttértár, ahol minden történelmi adatunk található, amelyeket kezelni tudsz, és amíg megőrizheted akarsz. Azt is megválaszthatja, hogy milyen típusú információt kíván megőrizni, és mennyi ideig. Ez valamivel visszatér, a megfelelő adatok összegyűjtésével és a felesleges adatok kihagyásával. Ha öt napig meg akarja őrizni a legeredményesebben teljesítő kérdéseket, majd két éven át megőrzi a figyelmeztetéseket, ez rajtad múlik, és ez teljes mértékben az Ön előjoga, hogy ezt megtehesse.
Számos különböző konzol a termékkel. Van web-alapú verziója, sűrű kliens-verziója is van. Ez tehát rugalmasságot kínál arra, hogy ugrik a böngészőn, és megnézze, mi folyik, vagy ha van laptopja, ahol van telepítve egy dedikált kliens, akkor ezeknek a megközelítéseknek az alkalmazása az ön számára megfelelő.
Most azt szeretném csinálni, hogy gyorsan bemutassam. És rámutatnék - visszatérek erre a másik diára -, amelyet nemrégiben adtunk hozzá, éppúgy, mint FYI azoknak a népeknek, akik ismerik a terméket, új ajánlatunk van, amely a Diagnostic Manager Pro. Professzionális ajánlat, amely magában foglalja valamit, amit Workload Analysis-nek hívunk.
És valójában arról van szó, hogy interaktív módon megnézhetjük nagyon hosszú időszakokat, és ebből - tudjuk, a 30 napos nézetből - tudod, egy ötperces nézetbe, kb. Három kattintással. És ha látni tudja a teljesítmény tüskéjét vagy a szűk keresztmetszetben felmerülő problémát, akkor valószínűleg nagyon magas szintű és nagyon alacsony szintű fúrásra képes látni. Különösen ez manapság is újdonság a termékben.
De amit én szeretnék tenni, az csak egyfajta első indulás, és szeretnék egy kicsit beszélni erről a forgatásról és oda-vissza. És hoztam egy példát, és itt fogok megosztani a képernyőn. És lássuk … Megyünk. Saját képernyőn. És tudassa velem, srácok, hogy láthatja.
Eric Kavanagh: Itt megy.
Bullett Manale: Oké rendben van? Rendben. Tehát, amit most néz - és ez a Diagnostic Manager termék -, csak azt akartam bemutatni, hogy mi történjen itt. Ebben a példában azt csináljuk, hogy megmutatjuk a várakozással összefüggő lekérdezéseket. És tehát, amikor arról beszélek, hogy képes oda-vissza menni, mélyebben fúrni és elfordulni, ez az - ez a nézet erre jó példa. Megismerhetek egy olyan idővonal-nézetet, mint amilyet itt látunk, amely most megjelenik. Esetünkben a várakozásokat és a várakozások kategóriáit vizsgáljuk. Láthatjuk azokat az állításokat, amelyek ezekhez a várakozásokhoz kapcsolódnak, láthatjuk az alkalmazásokat.
Figyelem, itt van egy idővonal-nézet, így lineárisan azonosíthatom az információt attól a pillanattól kezdve, amikor a probléma bekövetkezett, de akkor ismét, ha ismét el akarom forgatni, és azt mondom: „Tudod mit, nézzük meg ezt más perspektívából nézve, "menjünk tovább és nézzük meg ezt a szempontból:" Látni akarom azokat a kérdéseket vagy várakozásokat, vagy az alkalmazásokat, amelyek nekem okoznak leginkább fájdalmat, és rangsorolom őket. " látni fogjuk: „a lekérdezés az időtartam alapján vár.” Most látjuk azokat az alkalmazásokat, amelyek a legtöbb fájdalmat okozják, vagy a várakozásokat.
És akkor, itt van ez a rész, amely valóban a legfontosabb, az, hogy képes elkülöníteni ezeket a dolgokat. Látom, hogy ez a NoSQL alkalmazás elindul. Nagyon sok várakozási időt okoz nekem, jóllehet a 25 másodperces várakozási időbe azon a 30 perces ablakon belül, amelybe belefúrunk. Ezután el tudom különíteni az alkalmazást, és látom a jelen esetben azokat a megállapításokat, amelyek közvetlenül érintik ezt az adott példányt.
Tehát ez csak egy példa arra, hogyan tudná azonosítani a szűk keresztmetszetet, rangsorolni az információkat, és prioritássá tenni azokat a kérdéseket, amelyeket először kell kezelni. Mindezeket figyelembe kell vennie. Tudod, egész nap javíthatja a problémákat, de ha javítja a javítandó lista alján található problémákat, akkor pazarolja az idejét. Ehhez egy alternatív költség tartozik.
Adok egy másik példát, és ez egy kicsit más. Ahelyett, hogy kifejezetten egy problémára vagy egy területre mutatna, akkor is szüksége van egy eszközre, amely széles értelemben segíthet önnek abban, hogy azt tudja mondani: “Hé, volt valami problémánk?” Vagy “Vannak vannak dolgok, amelyeket megtehetek az előadás javítása érdekében? ”, és hogy legyen valami színfalak mögött, figyelve, mi folyik itt. És ebben az esetben ez kapcsolódhat a konfigurációhoz; kapcsolatban lehet azzal a móddal, ahogyan maga a példány egészségi állapotát kezeli. És nyilvánvalóan a teljesítmény-dolgok is.
Ha ide megyek az Elemzés gombra, akkor azt fogom mutatni, hogy ezen a terméken belül proaktív módon felsoroljuk azokat a dolgokat, amelyeket rangsorolt formában lehet végrehajtani, és amelyek lényegében betekintést nyújtanak Önnek. azokba a dolgokba, amelyek valószínűleg növelik az adott teljesítményt, vagy javítják az adott eset egészségét. És rangsorolt formátumban van abban az értelemben, hogy megvan annak a képessége, hogy megnézze, melyik nagyobb valószínűséggel javítja teljesítményét az azonosított problémák egy adott típusára jellemzően.
És tehát amikor ezeket a dolgokat átnézem és azonosítom, nemcsak azt látom, hogy problémám van, és sok esetben van egy olyan szkript is, amely automatikusan felépíthető a probléma megoldásához. De sok ilyen esetben külsõ linkekkel is rendelkezünk, amelyek hivatkoznak az általunk tapasztalt probléma típusára, majd miért adjuk ezt az ajánlást is, így megkapjuk a dolgoknak ezt az oktatási aspektusát. Melyikről ismét gondolom, hogy nagyon fontos, amikor beszél, tudod, a problémák megoldásáról.
Nem akarom csak vakon követni ezeket az ajánlásokat, szeretném megérteni, miért teszik ezeket az ajánlásokat. Lehet, hogy magas rangú DBA vagyok, aki ezt 30 éve csinálja, és szükségem van valamire, ami megy, tudod, ellenőrizze - vagy jelölje meg az i-et, és ebben az esetben keresztezi a t-jeleket -, vagy esetleg junior DBA vagyok és Kicsit segítségre van szükségem ezeknek a problémáknak a megértésében, ahogy azok történnek, és miért teszik ezeket az ajánlásokat.
Mint mondtam, csak átmegyek a termék néhány különféle részén. Ez az eszköz már működik, tudod, 2004 és 2003 óta működik. És valójában nagyon sok fejlesztés be van építve, rengeteg információ van, tehát nem lenne értelmes itt mindent megmutatni. De azt hiszem, hogy az egyik dolog, amit érdemes megjegyezni, az, hogy amikor belépünk, és elkezdünk beszélni minden olyan dologról, amelyet figyelhetünk, és minden olyan dologról, amelyre figyelmeztetni lehet, ismét visszatérve a dolgok ilyen rugalmasságához., itt található az összes megfigyelt elem felsorolása.
Ez nem feltétlenül jelenti azt, hogy ezeket a dolgokat riasztási állapotnak akarom tekinteni, ha a küszöbérték szempontjából kiszabadulnak, így ezeket be- és kikapcsolhatjuk. Erre visszavezetjük: „Hé, csak bizonyos méréseket kell tennem bizonyos mérőszámokhoz. Csak tudnia kell, hogy figyelmeztessen bizonyos problémákra. ”És képesnek kell lennie arra, hogy megbizonyosodjunk arról, hogy nem fogjuk tudni, hogy telítettünk egy csomó hamis pozitívummal. Nemcsak képes be- és kikapcsolni ezeket a dolgokat, de sok esetben észreveszi, hogy a normalitás sávját is megadjuk, mivel az az egyes mutatókra vonatkozik. Tehát, ha erre a konkrét, ebben az esetben egy kiindulási pontra néznék, észrevenném, hogy a küszöb valószínűleg magasabb ott, ahol jelenleg vannak.
Az érme másik oldalán az van, ha van egy SQL példányom, ahol néhány mutatót követek, és ezeket a mutatókat bármilyen okból hibásan állítottam be? Más szavakkal, a küszöbértékeket az a közepén kell megsérteni, ahol az alapvonal ténylegesen ült, vagyis ha van egy riasztás, amely ehhez a küszöbhöz kapcsolódik, akkor valószínűleg riasztást kapok valami számára, ami normális esemény. És tehát az ilyen típusú helyzetekben ezt a betekintést is nyújthatjuk Önnek.
Az adott mutató összes mutatója esetén látom azokat a küszöbértékeket, amelyek itt valószínűleg hamis pozitív eredményt mutatnak, ami a normál és mi nem. Ez olyasmi, amelyet inkább a memória oldalán szokásos használati dolognak tekintnek, és ha ezt a küszöböt szeretnék növelni, akkor tehettem volna, de ez az ötlet az alapvonalakkal.
És a Diagnostic Manager termékkel kapcsolatban remek dolog az alapvonalak szempontjából az a képesség, hogy több alapvonalat állítsanak be. És akkor felteheti a kérdést: „Miért szeretném ezt megtenni?”, És a válasz az, hogy ha van egy karbantartási ablaka, mondjuk, éjféltől reggel 4-ig, ahol tényleg adóztatja az erőforrásait, akkor "valóban a lehető legnagyobb mértékben használja az erőforrásokat, akkor ismét képes váltani, és egy kicsit elfordulni, és azt mondani:" Nézd, meg fogjuk változtatni a küszöbértékeinket. " És ténylegesen dinamikusan beállíthatjuk küszöbértékeinket, attól függően, hogy melyik alapállapotban vagyunk, a napszak vagy a hét napja alapján, és így tovább. Szóval dinamikusan beállítja ezeket a küszöböket számunkra.
Tegyünk egy lépést újra. Miután azonosítottuk ezeket a küszöbértékeket, miután átmentünk, és a riasztások felállításának és az értesítésnek a megteremtése és az esetlegesen felmerülő helyzetek ismerete szempontjából, itt ismét kiemelkedő fontosságú a rugalmasság. Azt akarja, hogy képes legyen riasztást adni bizonyos helyzetekben. Más esetekben érdemes lehet e-mailt küldeni valakinek, futtatnia kell a PowerShell szkriptet, tudod, hogy a lista folytatódik.
Integrálhatnék valamivel SNMP trap-en keresztül, vagy akár közvetlenül is, például a SCOM-nal. A lényeg az, hogy hajlandó megtenni ezt, és beállíthat olyan feltételeket, amelyek garantálnák, hogy nagyon széles körű feltétel legyen - tudod, a CPU és a memória, vagy bármilyen erőforrás - az összes példányomban, vagy talán van egy nagyon különleges típusú dolgom, amelyet figyelni akarok, mert amikor rájöttem, hogy sértünk, nagyon konkrét és irányított szkriptet akarok futtatni erre a problémára. Tehát itt tudsz ilyen dolgokat csinálni a Diagnostic Manager termékben, csak tudod, a riasztás és az értesítés szempontjából, és rugalmasak lehetnek ebből a szempontból.
Most nem fogok átvészelni az összes riasztást és az összes jó dolgot. Szerettem volna beszélni a jelentésekről. És ismét, hogy az információt számos módon felhasználhatjuk, és felhasználhatjuk ezeket az adatokat - és ez ismét visszatér az adataiddal folytatott beszélgetéshez. És sokan, amikor először látják ezt a terméket, azt gondolják: „Ó, nos, lesz egy eszközem, amely figyelmezteti a problémákat. Erre van szükségem. ”És a valóság az, hogy szükségük van-e erre az eszközre, de ennek másik oldala, ha valóban van - olyan eszközre is szükségük van, amely segít döntések meghozatalában, és felhasználhatják ezt az információt, hogy mi vagyunk gyűjtés a teljesítmény és a riasztás nevében, hogy elősegítsük az előrehaladást.
Tudod, jó példa erre a növekedési előrejelzéseim az adatbázisomban. Ha van egy specifikus adatbázisom, amely növekszik, akkor rá tudok mutatni arra az adatbázisra, vagy akár több adatbázisra is, hogy megnézhessem, mi a növekedési ütem. Nem azt mutatjuk meg, hogy mi alapján állunk, tudjuk, mi ez manapság; előrejelzi majd a korábban tapasztalt növekedés alapján.
Ha van néhány adatbázisam - amelyről valószínűleg elképzeltem, hogy van -, bemehetnék és mondhatnám: „Vegyük az utolsó, tudod, az évi értékű adatokat, korreláljuk ezt hónaponként és egy mintában havi ráta, menjünk előre és nézzük meg, mekkora növekedést fogunk látni az elkövetkező három évben, vagy 36 egység. ”Ebben az esetben nagyon gyorsan megválaszolhatjuk ezt a kérdést. Most próbáld meg ezt csinálni egyedül, igaz? Próbáld meg csinálni annyi idő alatt, mint én magam csináltam. Ez eltart egy darabig.
Most még egyfajta további hangsúlyozás céljából vegyünk egy másik jelentést, amely a legfontosabb szervereim jelentése. Képzelje el, hogy van száz produkciós példányom, ebben az esetben nem. De ha valaki odajön hozzám és azt mondja: „Szüksége van, hogy mondd el nekem - ki fogjuk állítani ezt az új adatbázist erre a nagyszerű új alkalmazásra; mindent meg fog változtatni, amint tudjuk; olyan csodássá teszi az életet. Ó, egyébként maga az adatbázis valóban I / O-intenzív lesz, vagy CPU-igényes, vagy valóban memóriaigényes lesz, "" bármi legyen is az a kitöltés, azt szeretném láthatom az összes termelési példányomat, hol van értelme az adatbázist feltenni? És az összes példányomat egymással szemben besorolhatom a függő típus szempontjából, legyen az CPU, memória, lemez vagy bármilyen eset is. Tehát itt a lényeg az, hogy gyorsan és hatékonyan megválaszolhatjuk ezt a kérdést, és helyes döntést hozhatunk, ahelyett, hogy kitalálnánk, mikor csináljuk - ezek nyilvánvalóan valóban nagyon fontosak, és szüksége van valamire, amely segít.
És amikor az analitikáról beszélünk, akkor az kezdődik, bármi olyan is lehet, mint amiről beszélünk a kapacitástervezésről, a figyelmeztetésekre, hogy napi rendszerességgel dolgozunk, amelyek esetleg a CPU-val foglalkoznak, mivel valamint nyilvánvalóan maguk a kérdések, függetlenül attól, hogy van-e blokkolás és így tovább, és így tovább.
Egy másik példa erre az lenne, ha itt mennék az adminisztrációs szekcióba - valójában visszavezem ezt a figyelmeztető szekciót -, és a múltban történt dolgokra vonatkozó lekérdezést kér a történeti információk letétkezelőjéből. Korábban blokkoltam már a termelési környezetemben? Nem tudom, derítsük ki.
Visszatérhetek a termelési címkémhez, és mondhatom, hogy az összes termelési példányomra, bármilyen időtartamot figyelembe véve, bármilyen mutatóra, amelyet azonosítani akarok. Ha riasztási állapotba kerültem, a mi esetünkben mondjuk, hogy a blokkolás szám szerint történik, nem pedig a blokkolás másodpercével, és visszamehetek, és ebben az esetben néhány hónapra, ha kell - vagy ebben eset, egy hónap - és látom, hogy ez blokkolja. Látom, mikor kezdődött, látom, mikor véget ért, és be tudok fúrni ezeket a húzási időközöket bármelyikbe, ha szükségem van rá, hogy megnézem a blokkoló esemény sajátosságait. Tudnia kell, hogy van valami, ami nagyon gyors, képesnek kell lennie arra, hogy megtalálja azt, amire szüksége van, és amit keres, ahelyett, hogy sok ciklust forogjon be, hogy befejezze. És úgy gondolom, hogy ez is fontos.
Az utolsó dolog, amit meg akarok mutatni neked - és megmutatom neked ezt a terméket, a Diagnostic Manager terméket -, hogy van - amint már korábban említettem - bementünk, és újabb komponenst adtunk hozzá az SQL Diagnostic Managerhez Pro ajánlat. És ez a Workload Analysis összetevő. És ez egy web alapú változat, ebben az esetben itt mutatjuk be Önnek. De a lényeg itt az, hogy ez lehetővé teszi egy igazán széles időtartamra vagy egy nagyon konkrét időszakra való áttekintést, és, tudod, néhány kattintással megnézheti a valószínűleg bekövetkező problémákhoz közvetlenül kapcsolódó kódot. .
Példa erre, ha négyhetes nézetet nézek, itt láthatom itt az összes szöget az adatbázisok és az adatbázisok teljesítménye szempontjából, és ott, ahol a várakozási tevékenységet láttuk azokon az adatbázisokon. Most, és láthatjuk, hogy ha tüskét látok itt, akkor ennek az eszköznek az előnye, hogy csak ki tudja emelni azt a kis sávot ott. És akkor, amikor ezt megcsinálom, az összes cucc megváltozik. Látnánk az adatbázisokat, láthatnánk, hogy az összes parancs hozzá van kötve ahhoz, ami a sáv mögött található.
Ugyanez lenne, ha azt mondanám: „Nézzük meg az elmúlt négy órát”, nem pedig az elmúlt négy hétre. Még mindig meg tudom csinálni. Még mindig kiemelhetem ezt az időszakot, majd onnan - itt ismét itt vannak a kulcstartó pontok - az összes ilyen dolgot itt összekapcsolhatom. A legfontosabb SQL utasítások, látom azokat a lekérdezéseket, ebben az esetben, amelyek várakozásokat okoztak, amelyek a CPU fogyasztásához kapcsolódtak. Csak befúrással látom az itt felmerülő kérdéseket - szopás -, és látom a programokat, és mi is ehhez társítva.
Nagyon sok betekintést kap itt, és nem csak ezt, de láthatja, hogy amikor a parancs szintjére jutsz, elmondja neked a dolgokat. Meg fogja mondani, lát-e nehéz operátorokat, majd megnézheti a végrehajtási terveket. Ez egy kis időt vesz igénybe, mert elég nagy a betöltés. De a lényeg itt az, hogy nagyon sokféleképpen megnézheted az adatokat, láthatod, mit keresel, és nyilvánvalóan képesek vagytok ott lépéseket tenni, amire szükségük van, tehát, és ez hosszabb, mint általában, tehát erre hagyom.
És tehát azzal, amit mondtam, vissza fogom adni. És remélhetőleg ez jó olyan bemutató volt, amiről beszéltünk. És amint mondtam, maga a termék, amelyet ilyen példák adására szoktunk, elég hosszú ideje létezett, és sok más dologról, amelyekről beszélhetnénk és megmutathatnánk, de ha ez valami érdekes Önök közül bármikor kiment a weboldalunkra, letöltheti és játszhat vele.
Eric Kavanagh: És szeretem, hogy mindezt elmutassad. Ha visszamenne egy pár képernyőre - még ez a képernyő is nagyon jó. Mivel oly sokféle módszer van a valódi események megjelenítésére, és azt hiszem, hogy ez manapság a számítások egyik alulbecsült aspektusa. Ez minden bizonnyal egy adatbázis-környezet, amelyben sok szempontból ezt a félig viccet mondom: „Még mindig megtanulunk beszélni a szilíciumról.” Még mindig megtanuljuk megérteni, hogyan kell megnézni, mi történik, és pontjukra, amely nagyon jól fogadták el, akkor kell beszélgetned az adatokkal, hogy jobban megértsék, mi folyik, miért megyek lassan a dolgok, mert oly sok lehetséges probléma van. És természetesen, az IDERA számos különféle termékkel rendelkezik, ezek közül az egyik a régi Precise termékek, amelyek szerintem kiegészíthetik ezt.
De talán Robin, néhány kérdéssel felveszem neked, majd Dez, pár kérdés tőled, és akkor talán a közönség valaki, ne légy félénk. Küldje el őket most.
Bullett Manale: Robin, néma vagy?
Robin Bloor: Igen. Jól van, csak elnémítom magam. Meg kell mondanom, hogy hihetetlenül - ez a dolog, ami valójában legdrámaibbnak tűnt ennél a szerszámnál, mert valójában - főleg az a tény, hogy egészen nyilvánvaló, hogy egy egész sorozat dimenzióba, amelybe éppen nem mész be - a dolog, amely valójában, Úgy gondolom, hogy ez a leglenyűgözőbb, ez egy igazán, nagyon jó módszer a DBA edzésére. Tudod, így van: tehát amikor először belekezdesz adatbázis-munkába, és valójában nem sokat tudsz arról, hogy mi történik egy adatbázisban, valójában nagyon nehéz megérteni. Tehát sokat használják ezt, kifejezetten az edzéshez? Használnám.
Bullett Manale: Igen. Úgy értem, amikor az edzésről beszélsz, úgy gondolsz, mint egy folyamatban lévő edzés, mint DBA-fajta, igaz? Ami a …
Robin Bloor: Igen, igen, igen, igen. Tanulási eszköz. Tudod, a.
Bullett Manale: Igen, biztosan azt gondolnám, hogy ez a helyzet, és még ennél is inkább, hogy hozzáadtuk ezt az Analyze összetevőt, amelyet korábban mutattunk Önnek, és amelyhez az összes ajánlás kapcsolódik. De azt hiszem, biztos, hogy a súgóban és a termék sokféle részén belül talál, tudnivalókkal sok betekintést nyújt Önnek. Sok információ.
És a valóság az, amint mondtam, akkor ezt is használhatja, ha nem DBA. Valószínűleg találsz magának néhány Google-keresést és hasonló dolgot, csak azért, hogy általában megismerhesd, mi van a legtöbb DBA-val, de ezt össze tudja kapcsolni, és ez határozottan segíteni fog Önnek: „Hé, tudod, hé, mi ezt a széttagoltságnak nevezett dolgot? ”vagy„ Miért fut ez a lekérdezés 6000-szer? ”Úgy értem, mert ezeket a dolgokat felveszik neked, és felbomlanak, és meglátod. Látni fogod, hogy tudod, mi a normális, és mi nem. Látni fogja azokat a dolgokat, amelyek tüskés, és azokat, amelyek nem.
Ezt a dolgot általában a legjobb gyakorlatok szempontjából próbáljuk felállítani. Tehát amikor egy példányra mutat rá, megmutatja azokat a dolgokat, amelyeket a bevált gyakorlatokon kívül esnek. Úgy értem, természetesen, tudod, a valóság az, hogy a bevált gyakorlatok a legjobb gyakorlatok, és nem mindig valós gyakorlatok. De tudod, ez megmutatja a távolságokat, még a telepítés kezdetétől, és egy példányra mutat.
És akkor onnan mozoghat tovább, mivel feltétlenül meg kell javítania a problémákat, és meg kell határoznia, hogy ez valóban probléma, vagy valami, ami általában napi szinten történik. És azért, mert nagyon sok információ van a segítségére, és az ajánlások, igen, feltétlenül.
Robin Bloor: Jól van. És egy másik kérdés - de biztos vagyok benne, hogy erre a kérdésre nagyon gyors válasz van - az, hogy megvan a részletessége, hogy egyenesen az egyéni lekérdezéshez és az egyedi időponthoz menjen, és ebből a dimenzióból nézzen, .
Bullett Manale: Persze, igen. Attól függően, hogy mit akar csinálni, megnézheti egy perces időablakot, vagy megnézheti egy háromnapos időablakot, vagy tudod, egy háromhetes időablakot. És tudod, amint mondtam, attól függ, hogy miként akarja megnézni az adatokat, és azt is, hogy mit szeretne gyűjteni. Egyes esetekben csak azokat a lekérdezéseket gyűjtjük, amelyek elérik az Ön által meghatározott küszöböt. Más esetekben összegyűjthetjük minden tudnivalót, amely várakozást okoz.
De azt is meg tudja mondani: „Nézd, azokat a küszöböket, amelyeket azonosítottam, talán csak írásokhoz, vagy csak olvasásokhoz, vagy talán csak CPU-hoz.” Tehát, ha feltételezzük, hogy túllépte ezt a küszöböt, akkor az Ha bármilyen időkeretet szeretne megnézni, akkor láthatja azokat a lekérdezéseket, amelyek sértőek, és azon alapulnak, amelyet Ön szerint sértőnek tekint.
Az adatok megnézésének sokféle módja van. Összevont nézetben megnézheti azokat a kérdéseket, amelyek - hány a színfalak mögötti lekérdezés elindult, szemben azzal, hogy a lekérdezés minden egyes eseménye elindul, mintát nézni, ha akkor látni fogja, hogy folyamatosan rosszabbodik-e.
De ahhoz, hogy megválaszolja a kérdését, határozottan rámutathat arra, hogy mikor kívánja. Önnek van ez a történelem böngészőnek nevezett fájl - és én egy kicsit valamivel használtam -, de alapvetően bármilyen időpontban, amelyet választott, a kiválasztott naptár bármelyik napján, közvetlenül oda is mehet az idő.
Jelenleg november 15- én, 19 : 05-kor nézek, és megnézhetjük az adott időpontra vonatkozó kérdéseket. Ha lennék olyanok, amelyek rosszul futnának, figyelembe véve azt az időablakot, akkor megnézhetnénk az adott időablakra jellemző munkamenet részleteit, hogy megnézhessük, melyik munkamenet fut. Úgy értem, itt rengeteg adat van, és amint mondtam, valójában a legnehezebb a talán 30 perc játék a konzollal, és kitalálni, hogyan kell csinálni ezeket a dolgokat.
De ha egyszer felismeri, hogy az itt található adatok többsége ebben a szalagban van, és ezek meg vannak osztva ezekkel a lapokkal, és minden lapnak megvan a saját dinamikusan változó gombjai, amelyek minden alkalommal megjelennek, amikor rákattintanak, akkor valóban időbeli vagy egyéb dolgok, amelyek történt a múlt héten, ugyanaz a folyamat. Alapvetően én most november 15- ig nézek, de ugyanolyan könnyen megnézem a valós időt is, ha rákattintok a gombra. És az adatokkal ugyanúgy fogok kölcsönhatásba lépni.
De ahhoz, hogy válaszoljon a kérdésére, igen, a történeti információk megtekintéséhez sokféleképpen van mód, és ez vonatkozik magukra a lekérdezésekre is.
Robin Bloor: Látom. Nagyon lenyűgöző. És nagyon szeretem azt a tényt, hogy az ablakok szinkronizálódnak, annak ellenére, hogy ez manapság nagy szükség van mindenre, amely manapság valósidejű adatokkal foglalkozik.
Bullett Manale: Igen. Biztos.
Robin Bloor: Itt csak egy olyan információ pont, amelyre valójában nem tudom a választ. Mivel ajánlata - SQL Server és a felhő - mutathat a felhőre a Ratio alatt?
Bullett Manale: Tudod. Ezt a felhő alá mutathatja. Amikor valóban hozzáad példányokat, akkor megkérdezi, hogy ez RDS vagy Azure. Most vannak bizonyos korlátozások attól függően, hogy mi kerül felénk a felhőből, tehát van egy - van egy kis különbség a megfigyelés szempontjából, egyszerűen azért, mert a műszerek bizonyos esetekben nem Nem áll módunkban összegyűjteni, annak alapján, amit a Microsoft kitár.
Nos, ha ez valami hasonló, az infrastruktúra mint egy platform, mint például, tudod, vagy az EC2 vagy valami hasonló, akkor ez egyáltalán nem jelent problémát. Mindent megkapunk. Ahogy a Microsoft-szal és az Amazon-szal dolgozunk; azon dolgozunk, hogy ezeket az információkat részletesebben feltárjuk. De teljesen igen, támogatjuk ezeket a környezeteket.
Robin Bloor: Oké, ez érdekes. Nos, átadom Deznek, aki biztos vagyok benne, hogy más irányból ad fel kérdéseket.
Bullett Manale: Jól van.
Dez Blanchfield: Köszönöm. Két nagyon gyors nekem van. Azt hiszem, tudod, az első a mérleg, tudod, azt hiszem, az egyik dolog, ami engem felhív, az az, hogy az előadás általános témája általában valami olyan, amire gondolkodunk, amikor nagyon nagy, nagyon nagy leszünk, nagyon nagy méretű, széles és terabyte-os adat. Figyelembe véve a demo-t, feldöbbent, mivel ez valójában vonatkozik még a nagyon kicsi környezetre is, valahogy csak előadás-slágerekre.
Milyen elterjedését látja ennek elterjedésében, és úgy gondolja, hogy ez, tudod, azt hiszi, hogy ez egy eszköz, amelynek jó, tudod - az a véleményem, hogy igen, tehát azt hiszem, hogy igen - de nagyon szívesen látom, amit látsz. A kisebb szervezetek ugyanazokkal a beszélgetésekkel beszélnek, és eszközöket keresnek erre, vagy valóban valami a város nagyobb végén?
Bullett Manale: Vicces - ez jó kérdés. Ez egy kis keverék, de azt mondanám, hogy van egy csomó kis ügyfelünk. És amikor azt mondom, hogy a kis ügyfelek, akkor azt értem, tudod, hogy egy-öt példányos vásárlás történik licenc céljából. Most bizonyos esetekben lehet, hogy van 30 példányuk, igaz, az SQL, és valójában csak az öt érdekli őket, tényleg annyira fontosak, hogy egy ilyen eszközbe fektessenek be az öt példányra.
De a valóság az, hogy még kisebb üzletekben is van egy maroknyi SQL-kiszolgáló. A legtöbb esetben vagy sok esetben az a kis üzlet nagyon, nagyon függ az adatbázisoktól, tudod, hogy mit csinálnak. És így nem, nem engedhetik, hogy lemenjen. Nem tudják, eszköznek kell lenniük.
Az érme másik oldala az, hogy néhány kisebb üzletben nincsenek külön DBA-k, tehát az a srác, aki a szobában a legokosabb fickó, vagy a szobában lévő technikusabb fickó, a végén a kijelölt DBA. Tehát ebben a helyzetben határozottan keresnek segítséget, és ez az eszköz nyilvánvalóan ebben is segít nekik.
Nagyobb környezetéhez, mivel azt hiszem, hogy Dez említette - vagy Robin, nem vagyok biztos benne -, de tudod, hogy a nagyobb környezetekben meglepődni fog, hogy hány DBA-k vannak, úgy értem, mi ' hatalmas számú SQL példányt beszél, és szó szerint néhány maroknyi DBA-t kaptál, amelyek feladata, hogy felelősek legyenek értük. És tehát ebből a szempontból ezek a srácok, tudod, keresnek valamilyen segítséget, mert nincs elég erőforrásuk ahhoz, hogy valóban segítsenek nekik, és így egy eszköz segít ellensúlyozni ezt.
Tehát azt is látjuk, hogy jó, ha tudod, három srácuk kezeli a 200 példányt. Tehát el tudod képzelni ennek logisztikáját, ha nincs ilyen eszközük, hogy megpróbálják kitalálni, mikor van még probléma. Ez nem lesz proaktív módszer, biztosíthatom önöket. Tehát remélhetőleg ez válaszol a kérdésére. Igen.
Dez Blanchfield: Igen, igen. Ez sztrájkolt - és azt hiszem, hogy Robin erre utalt -, de, tudod, az a fajta ígéret, amelyet Ön leír, amikor elkészítette a demo-t, úgy értem, hogy nem kizárólagosak a nagyon nagy környezetekben. Tudod, vásárolhat egy közönséges, egy dologhoz tervezett platformot, és valami másra helyezheti az adatbázis megosztott környezetébe, és ez csak az egész környezetet megbünteti.
A másik dolog, ami feldöbbent - ez nem annyira kérdés, hanem csak megfigyelés, viszont ez egy kérdéshez vezeti - és ez az, tudod, amikor a szervezetek már befektettek infrastruktúrájukba és platformot és azok adatbázisát, valamint a kiszolgálókat és az azt körülvevő infrastruktúrát, és bármit is vásárolnak egy terméket - HR-t, ERP-t, BI-eszközt - máris meglehetősen nagy beruházást hajtottak végre.
Milyen választ lát, amikor beszélgetsz az emberekkel, és rájöttek, hogy problémájuk van a teljesítményről, ám most úgy érzik, hogy még újabb beruházást kell végezniük erre a célra? Van-e olyan pont, ahol rájönnek, ha egyszer demonstrálják, hogy ők ezt a dolgot nem bátorságossá teszik, és ez nem annyira értékesítési pálya, hanem inkább epipánia. Tudod, ez csak az, hogy hamarosan meglátjuk ennek előnyeit. Ellentétben azzal, hogy csak a terméket kell eladnunk? Nekem úgy tűnik, hogy eladja magát, és a ROI csak leugrik az oldalról.
Bullett Manale: Igen, és ez vicces, hogy ezt mondod, mert sokszor előfordul, hogy valaki eljön, mint egy DBA vagy akár az értékesítési képviselő is, és azt fogja mondani: “Hé, ezek a srácok szeretnének lásd egy ROI-lapot ezen. ”És inkább egy, valami papírt, amit nekik küldünk. És a demo mindig tízszer jobb, főleg az, ha megteszed magad a DBA-kkal, mert -
Dez Blanchfield: Igen.
Bullett Manale: Mint mondtad, a termék maga is eladja magát. Nagyon nehéz ROI-t helyezni egy darab papírra, és azt mondani: „Oké, általában hány kattintást hajt végre egy DBA, tudod, kattint egy órán belül?”, Mivel a biztonsági másolatokra vonatkozik, tudod, vagy bármi legyen is az eset, tudod? És ezt megpróbálni egy darab papírra tenni, nagyon nehéz ezt megtenni. De amikor kap valakivel, és megmutatja nekik a terméket, és látják, pontosan ezt mondtad.
Az emberek felismerik annak értékét. Mert nem csak segít megérteni és jobb döntéseket hozni, hanem az is segít, tudod, hogy nekik ne legyen rossz fiú. Ők lehetnek az elsők, akik megismerik; kijavíthatják a problémát, mielőtt még valaha is felismernék, hogy probléma van.
Ennek másik része az, hogy DBA-ként tudod, függetlenül attól, hogy ez valódi, vagy valódi vagy érzékelés - és azt hiszem, ez az észlelés - valójában a teljesítményproblémák tulajdonosa vagy. Te vagy az a fickó, aki az ujjával rád mutat, amikor a teljesítmény lemerül, és a valóság az, hogy valójában a fejlesztő okozza a problémát.
Ha van egy eszköz, amely képes mondani: „Hé, ez nem az én problémám, képesnek kell lennem arra, hogy elviszem ezt a fejlesztőhöz, és ezt ki kell javítaniuk”, vagy, tudod, e vonalak mentén. Ez egy jó módszer arra, hogy van valami az arzenáljában, és mondhatjuk: „Itt van az igazi probléma.” Tudod?
Dez Blanchfield: Igen. Az utolsó számodra, és az a dolog, ami engem sztrájkol, amikor ezt áttekintettük, az az volt, hogy amikor gyakran gondolkodunk a teljesítmény kérdéseire, hajlamosak vagyunk speciális készségeket behozni. 20 éves tapasztalattal jönnek, megnézik, és egyfajta, tudod, a srác klasszikus viccévé válnak, aki bemegy a mérnöki üzletbe, és van egy apró kalapáccsal, és a megfelelő helyre csapja a gépet, majd azt mondja:, „Ez egy 15 000 dolláros fix összeg”, és az emberek ezt mondják: „Nem fizetünk érte”, tudod, mert öt perc a munka. És azt mondja: "Nos, az öt perc munkájához 15 éves tapasztalat szükséges, és ez milliókat takarított meg."
Számomra úgy tűnik, hogy tudod, van egy középső folyamat, amikor az emberek ezt a dolgot megrajzolják, mondván: „Oké, hozza be a speciális képességeket, javítsa ki a problémát, ez megszűnik.” De amit akkor csináltak, az éppen feltettek egy Band-Aid-ot, igaz? Ellentétben egy olyan forgatókönyvvel, ahol az itt látható dolgok közül, hol, amikor ez bekövetkezik, igen, valószínűleg foglalkoztak olyan teljesítményproblémákkal, amelyekről azt gondolták, hogy megtapasztalják, de nekem úgy tűnik, akkoriban csak ezt a 24 / 7 fajta, tudod, egy sor szem, amely valós időben figyeli a környezetet.
Valójában elszállt a forgatókönyvtől, amikor a DBA-k reggel négykor felébrednek, mert a jelentések futnak. Ez a helyzet - és talán retorikus -, de vajon az emberek gyorsan áttérnek egy termékbe történő befektetés iránti vágyra, hogy egy adott problémát megoldjanak, ám ez általában csak a DNS részévé válik?
Bullett Manale: Igen, és helyről-helyre változik, de úgy értem, van néhány ember, aki eredetileg megvásárolta a terméket, mint például 2006-ban, és három különböző munkahelyen jártak különböző vállalatoknál, és bementek, és amikor elmennek a következő cégbe, ezt reklámozzák, mint valami megszerzésre kerülő lehetőséget, mert munkafolyamatuk van. És ezt nevezném, utálom ezt nevezni, de tudod, hogy a munkafolyamat magában foglalja ezt a terméket, és napi szinten hozzászoktak hozzá, és ez segít nekik, és így nem akarják tanulni valami újat.
De teljesen. Úgy értem, hogy az emberek legtöbbször letöltik ezt a terméket, nem azért, mert költségvetésük van, és mert kimennek, és azt mondják: „Hé, Nos, van ez a teljesítmény-költségvetés, meg kell tennünk a koncepció bizonyítéka, és be kell lépnünk, kitalálnunk, ki kell értékelni és meg kell csinálni mindazt. ”Általában az történik, hogy problémájuk van egy SQL példányban, és segítségre szorulnak javítsa ki ezt a problémát. Elmennek és letöltik az eszközünket, kijavítják a problémát, majd rájönnek, hogy ez az eszköz maga nemcsak a probléma megoldására szorítkozik, amely akkoriban volt, hogy ez valóban elősegíti számukra az általános teljesítmény javítását. és tartsa fenn más problémákat a továbblépéstől. És ez biztos. És határozottan továbbra is használhatja ezt az eszközt a környezet folyamatos hangolására, mivel mindig látni fogja nem csak azt, ami most történt, hanem azt is, ami történt a múlt héten, a múlt hónapban, a múlt évben, és összehasonlíthatja azt azzal, ami fog történni. holnap. Tudod? Afféle dolog.
Dez Blanchfield: Igen.
Bullett Manale: Szóval, biztos.
Dez Blanchfield: Tökéletes. Tehát megemlítette, megemlített valamit az alábbiakról: Csak bepakolok, mielőtt visszaadom Ericnek, hogy bezárjam. Az egyik dolog, amelyben mindig érdekel, az, hogy tudják, hogyan kapják meg az emberek a kezét? Ön említette, töltse le. Mi a 30 másodperces összefoglaló arról, hogyan kapják meg a kezüket, kapnak egy másolatot, felcsavarják és játszanak vele, és mire lehet szükségük infrastrukturális szempontból, csak egy példány beszerzése érdekében.
Bullett Manale: Szóval így lesz, elmegy az IDERA (idera) .com webhelyre. Az IDERA.com a cég, és ha eléri ezt a weboldalt - és valójában itt is megmutathatok -, nem tudom, hogy továbbra is megosztom-e a képernyőmet, de ha a Termékek oldalon megy, akkor lépjen a Diagnosztika Menedzser link, lesz egy kis Letöltés gomb, és csak letöltheti az összeállítást, miután kitöltette az információkat. Megkérnek tőled a 32 vagy 64 bites verziót, és máris részt vesznek a versenyeken, ahogy mondják.
Dez Blanchfield: És fut-e rajta laptop, hogy valaki játszhasson vele, vagy valahol szerverre kell töltenie?
Bullett Manale: Nem, nem. Valójában az, amit ma megmutattam, az mind a laptopomról futott. Most a laptopom 32 koncerttel és 8 magos processzorral rendelkezik, de még mindig laptop. De a kérdés megválaszolásához nem feltétlenül szükséges annyi erőforrás. Maga az értékelés 14 napra jó, ám örömmel örülök, ha hosszabb próbaidőszakot ad neki. Ha csak felhív egy telefonhívást, kibővíthetjük az Ön számára, ha szeretné.
Dez Blanchfield: Azt hiszem, hogy ezt el kellene venni, mert határozottan meg fogom csinálni. Azt hiszem, tudod, hogy a dolgok kinézetéből számomra nem gondolom, hogy töltse le és játssza le. Valószínűleg megy valamelyik környezetébe, és csak látja, amit lát, mert azt gyanítom, hogy - mint minden, amit az elmúlt 20 év alatt láttam egy adatbázis-háttérben, amely engem megöreged -, ha egyszer meglátja, mi van a motorháztető, elképesztő, amit rájöttél, hogy gyorsan javíthat, és csak kis teljesítménynövekedést szerezhet.
Félelmetes, köszönöm a bemutatót. Nagyon nagyszerű volt. Köszönöm, hogy minden alkalommal megvitattad a kérdéseket.
Bullett Manale: Üdvözöljük. Kösz érte-
Dez Blanchfied: Eric, vissza foglak adni neked.
Eric Kavanagh: Igen, van egy nagyon jó kérdésünk a közönség tagja részéről. Te erről beszéltél a bemutatóban, és valójában tweetelt erről, mert nagyon jó idézet volt. Azt mondta, hogy nem akarja használni olyan eszközt, amely figyelemmel kíséri a teljesítményt, amely negatívan befolyásolja a teljesítményt.
Bullett Manale: Igaz. Úgy van. Ez a teljesítmény-figyelő eszköz fontos része, az nem okoz teljesítményproblémákat. Pontosan igaz.
Eric Kavanagh: Pontosan. Nos, olyan, mint azok a megsértett - olyan, mint a vírusellenes programok, amelyek pusztíthatják a rendszereket. Úgy értem, számos különböző technológiát használtam olyan műsorszóráshoz, ahol az antivírus program beindul, és csonkolja az adatfolyamát. Tehát vannak olyan dolgok, amelyek történnek, amelyekre Ön nem számít, de a kérdés az adott konkrét megjegyzéshez kapcsolódik. És milyen előadási slágereket látsz? Két százalék, öt százalék, egy százalék? Van számok, amelyeket ránk dobhat?
Bullett Manale: Nos, úgy értem, hogy ezzel a kérdéssel kihívást jelent, hogy tudod, a vita egy része, amelyről korábban beszéltünk. Tudom adni neked - általában egy-három százalék körül válaszol a kérdésére. De van még magyarázat, amelyre véleményem szerint szükség lenne, azaz sokféle lehetőséget kínálunk Önnek, hogy elmondja az eszköznek, hogy mit szeretne figyelni, igaz? És így visszatér erre. Nos, talán szeretnék mintát szerezni minden futó lekérdezésről. Tehát szeretnék egy olyan eszközt, amely elég rugalmas ahhoz, hogy bekapcsolhassa, így láthatom.
Tehát ennek a rugalmasságnak egy része magában foglalja, költségekkel jár. Ha további adatokat kell gyűjtenem, mert szeretnék egy mintát minden, az utoljára futó lekérdezésről, tudod, 20 perc alatt bekapcsolhatom ezt és meg tudom csinálni. És tehát, de általánosságban szólva, igen, egy-három százalékot látunk az általános költségek szempontjából. De ez változhat, és a legtöbb az attól függ, hogy milyen dolgokat kapcsol be és kapcsol ki - küszöbértékeitől függően - mennyi adatot szeretne gyűjteni, a szavazási intervallumokat, az összes ilyen dolgot hogy.
Valójában, ha elmész magának a kezednek a példányhoz, akkor az egyik dolog, amit meg fog látni, több szavazási intervallummal rendelkezik, amelyeket megadhat. És ez egyszerűen azért van, mert azt akarjuk, tudod, nem kell mindenképp ellenőriznem - Ha szívverést akarok ellenőrizni egy példányon, akkor nem kell a CPU-t és minden másat lekérdezni, ha 20 másodpercenként csinálom. Szóval több szavazási intervallum van, amelyet megadhat.
Mint mondtam, a lekérdezés-megfigyeléssel is rendelkezik, amelyet megadhat. And this can be done for each instance independently, so you can really cater to that specific instance in terms of what you want to monitor. For my wait statistics and wait monitoring, I can turn that on or off. And I can tell it to capture everything, I can tell it, you know, what I want to capture and when I want to capture it. So a lot of that will also– You have to take into consideration what you're doing, in terms of what you're telling the tool to monitor.
But generally speaking, what I would say, is, like I said, around one to three percent is what we see. We've been selling this tool a long time – since, like I said, about 2003 or 2004 – and we've got thousands of customers, so I can assure you that, you know, we don't have– we try our best not to cause performance problems in the name of performance.
Eric Kavanagh: Yeah, that's really good information. I just thought that was a brilliant quote because, you know, again, you don't want to defeat the purpose of what you're trying to accomplish, right?
Bullett Manale: Exactly.
Eric Kavanagh: And I appreciate Robin's question, too; this really is an excellent platform for helping DBAs understand the many different aspects and dimensions and layers of what we're talking about. And I think the concept of conversation with your data is highly appropriate here, because, to your point earlier, you're not gonna figure it out on the first try, usually. You need to spend some time looking at the data, looking at historical data, doing that synthesis in your mind. And that's the job of the human, right? The job of the profession that sits back there and takes heat from the business on a fairly regular basis, to get that job done and to keep the trains running on time, right?
Bullett Manale: Absolutely.
Eric Kavanagh: Well, folks, this has been another fantastic event. If any question you asked was not answered, by all means, let me know. Send an email to . We do archive all these events, so you can always go to InsideAnalysis.com to find the archive, or go to our partner, Techopedia.com. If you look on the right-hand side of their page, you will see Events, and the webcasts listed there. If you click on More Events, you can see all of the webcasts that we do listed there, past, present and future.
And with that, we're going to bid you farewell. We've got five more webcasts for the rest of this year, folks. We may schedule one more. But otherwise, it's going to be on to 2017. The ed cal is out. Let us know, and if you have someone that wants to showcase their technology, send an email to .
With that, we're gonna bid you farewell, folks. Thanks again for your time and attention, we'll talk to you next time. Vigyázz magadra. Bye-bye.
