Performance játék: búcsút mondhat a késésről

A Techopedia munkatársai, 2016. május 9

Elvihető: A házigazda Eric Kavanagh interjút készít Mark Madsenről, Dez Blanchfieldről és Bullett Manale-ről a késésről és a teljesítményről.

Jelenleg nincs bejelentkezve. Kérjük, jelentkezzen be vagy jelentkezzen be a videó megtekintéséhez.

Techopedia tartalompartner

A Techopedia munkatársai kapcsolatban állnak a Bloor Csoporttal és kapcsolatba léphetnek a jobb oldali lehetőségekkel. Kattintson ide az ipari partnerekkel való együttműködésről.

• Profil
• Weboldal

Eric Kavanagh: Hölgyeim és uraim, üdvözlet és üdvözlet újra a Hot Technologies-nál! Igen valóban! Eric Kavanagh vagyok, ez a Hot Tech show, a Techopedia jó barátaival való partnerség. Ugorjon online a Techopedia.com webhelyre a vállalati technológiák széles körű legújabb frissítéseiről; természetesen a fogyasztói cikkeket is lefedik. Itt a vállalkozásra összpontosítunk a programunkra, tehát ma fogunk csinálni.

Van egy hely a valódi és elegendő rólam kapcsolatban, engem felfedez a Twitteren @eric_kavanagh, szeretem a Twitter-et, szeretem megnézni ezeket a dolgokat, ez egy nagyszerű lehetőség az emberekkel való kapcsolattartásra, jó beszélgetésekre és egyoldalú - egy beszélgetés.

Szóval miről beszélünk? Ez az év forró, ez a lehetőségek egy egész világa, amelyet ma az információkezelés világában tekintünk, és amiről ma beszélünk, lekérdezések lesznek, az felgyorsítja a lekérdezéseket.

Azt hiszem, elfelejtettem megemlíteni a „Performance Play: Mondj búcsút a késésről” címet. Nos, ki akar késést? Senki sem akar latenciát, a lappangás az, amikor ott ül, rákattint a gombra, és várja meg, hogy történjen valami, és ezt senki sem akarja. A gyerekeknek nem tetszik, nem gondolják, hogy ez jó, a felnőtteknek sem tetszik. Mindannyian elrontották az internet sebessége, és gyorsan szükségünk van a dolgokra, most meg akarunk dolgokat, és ma mindent erről beszélünk ma a műsorunkban.

Mark Madsen elemző ma nálunk van a harmadik természetből, az egyik törvényhozónkból. Új adattudósunk, Dez Blanchfield, felhívja az ausztráliai Sydney-t. És akkor Bullett Manale, igen, valójában ez a neve, valójában állítólag két T-nek lenne. Bullett Manale az Idera vendégétől van, egy nagyon-nagyon érdekes cég, nagyon sok dolgot csinál. Már tudok róluk, amelyek közül az egyik egy idővel ezelőtt megvették a Precise nevű céget. Tudtam, hogy Zohar Gilad nevű vezérigazgatójuk, hogy van ez egy névvel? Egy fasz volt egy okos fickó.

De az emberek, fontos szerepet játszik ebben a webes közvetítésben a feltett kérdésekben, ezért kérjük, ne légy félénk, bármikor küldje el kérdéseit - ezt megteheti a webcast-konzol Q & A elemével, az ott lent a jobb alsó sarokban. Beszélgethet velem is, és beszélgetni fogok a hangszórókkal. Már van valaki, aki felhívja olaszországot, így: „Ciao, ciao. Gyere stai?? Rendben, ezzel átadom Mark első sorát, és átadom a fedélzetet Marknak. Mark, most megvan a WebEx. Vedd el, a padló a tied.

Mark Madsen: Köszönöm, Eric. De nem a közepén indulok, hanem az elején indulok. Szóval csak néhány megjegyzés a Dez és Idera-val folytatott megbeszélés felállításához, egyfajta államfejlesztéshez, adatbázisokhoz és műveletekhez. És tudod, ha erre nézel, akkor az adatbázis és az alkalmazások piacán még mindig vannak ilyen két világprobléma, mivel a fejlesztők a DBA-kat az embereknek tekinti, akik ezeket zavarják. Ki kell építenie az adatmodelleket, nem férhet hozzá ehhez, nem hozhatja létre azt, nem tehet indexet az adatbázis minden táblájának minden oszlopába, hogy gyorsabb legyen. És természetesen miért van szükségünk a modellekre? Ez csak az adatstruktúrák, ha megváltoztatjuk őket, nem tudja kiírni őket soros formában?

A probléma az, hogy a fejlesztők ismerik a kódot és az alkalmazásokat, de két dolog, amelyeket gyakran nem ismernek, a párhuzamosság, az egyidejű programozás, valamint az adatbázisok és alattuk levő operációs rendszerek. Kernelfejlesztőként, valamint operációs rendszerek és adatbázisok mellett elmondhatom, hogy az egyidejűség és a párhuzamosság valóban nehéz, és így sok olyan dolog, amit megtanulsz, hogy jó teljesítményt szerezzen a kódjából, valóban szétesik, amikor adatbázis-kezelés. És a teljesítmény nagyszerű, a tesztkörnyezet nagyon jó, a Q & A környezet pedig eltalálja az igazi rendszert, és hirtelen nem olyan nagy. Mivel sokrétű, hogyan működik a kód az adatbázisgal, hogyan működik a környezettel, és az igazán egyszerű kis gyakorlatok drasztikus hatásokkal járhatnak, attól függően, hogy milyen skálát futtat.

És amikor elkezdesz beszélni a külső alkalmazásokról, akkor természetesen a külső felületekkel rendelkező alkalmazások, a webes alkalmazások nagyon nehézek lehetnek, mert a dolgok nagyszerűek, amíg hirtelen lapossá válnak, és nem. Megtalálja ezeket az érdekes fennsíkokat, amelyek megértéséhez sok árnyalat szükséges.

A dolgok csúcspontja a DBA nézet. A DBA véleménye szerint vannak műveletek, idejük nagy részét, 80–90 százalékát, ops-ban, és talán 10–20 százalékot töltik el az előzetesen folyó fejlesztési dolgokkal. Ebből a szempontból vagy most fizet, vagy később fizet, és ha minden idejét előzetesen költi, akkor később sokkal jobb esélye lesz, szemben a fejlesztéssel, amely inkább egy funkció felfedezésére irányul. és próbáljuk kitalálni, hogyan lehetne a legjobban megtenni a dolgokat. Tehát problémáink vannak, és most már összeegyeztethetetlen módszertanok vannak - folyamatos telepítés, az alkalmazások gördülékenyítése, amikor készen állnak, a kódkiadás rendszeresen megtörténik, egy üzletben dolgozik, amely gyakorlati fejlesztéseket végez. Ez a fajta felgyorsítja a fejlesztést, de az adatbázis körül zajló gyakorlatok, valamint az, hogy mit tesznek a DBA-k és milyen rendszermenedzsereket képeztek ki, az IT-operációs gyakorlatok nem tartottak lépést.

Ha erre gondol, a legtöbb DBA változás-vezérlő környezetben működik, szemben a folyamatos telepítési környezettel. A stabilitásról és az irányításról szól, szemben a változás sebességével és a visszafordíthatósággal. Folyamatos telepítés, ha nem sikerül visszatérni a változásokból, bajban van, ezért mindent meg kell építeni, hogy könnyen visszafordítható és kódváltható legyen, ami nem igazán az, ahogyan a relációs adatbázis, a fejlesztési gyakorlatok és a kezelési gyakorlatok működtek. .

Önnek ezen a problémáján is szembe kell néznie azzal, hogy proaktívabbnak kell lennie, ha DBA-ként tudsz, mert a probléma meghallgatásának idejére száz ezer ember tölt be panasztételi űrlapokat az Ön webhelyén. Ezért szüksége van néhány újdonságra, amelyeket nem szabad kijuttatni a régi környezetből. Tudod, olyan dolgok, mint a jobb figyelés és riasztás. Ugyanakkor az adatbázisok sokszorozódtak, több alkalmazáshoz jutottunk, mint valaha, és soha, mint valaha, belül vannak, kívül vannak, mindenütt vannak. És az elemzésekhez függetlenebb adatkészletekkel az emberek egészen adatbázisokat indítanak, mert természetesen most könnyű, beállíthat egy virtuális gépet. Ha van felhő szolgáltatója vagy belső felhő, azonnal felbukkanhat a dolgok, és ez megváltoztatja a teljes beszerzési utat.

A régi beszerzési út: „Van ideje szerverhez jutni, egy rackbe dugni, helyet kiosztani, tárhelyet szerezni, az adatbázist telepíteni és megtenni”, szemben azzal, hogy valaki elcsúsztat egy hitelkártyát, és öt perc múlva elindul. Ha ezt megteszi, akkor a modern fejlesztési környezet nagyon eltérő ütemben működik, és így könnyű adatbázisokat létrehozni, és ez csak megteremti a proliferáció problémáját, mint amilyet eddig még nem láthattunk. És ez már tíz éve folyik, ez senkinek nem hír, hanem azt is jelenti, hogy a működési környezet komplexitása megnőtt.

Az egész ügyfélkiszolgáló-környezet valóban megváltozott, mivel ez már nem ügyfélkiszolgáló-világ. Akkor volt egy szerver, egy adatbázis, és ha valami nem volt rendben, tudta, hogy a szerverhez menjen, tudta, hogyan kell kezelni a rajta található erőforrásokat, mert a legjobb gyakorlat egy adatbázis, egy szerver volt. A virtualizáció elkezdte széttöredezni ezt a különbséget, a felhő még inkább megszakítja, mert az adatbázis szervernek gondolod csak szoftver. Tehát a környezet nem valódi. Ez az, ami tartalmazza a környezetet, a valóság, és valószínűleg nem egy pengetartó vagy egy darabra vágott nagy szerver, nem igazán tudod.

Az adatbázis-adminisztráció és a teljesítmény menedzsment körül, és az adatbázisokat egy kiszolgáló, vagy egy maroknyi kiszolgáló és egy pár adatbázis szoros ellenőrzése körül építették, és mindent nem lehet ellenőrizni. Itt ülsz egy gépen, de a sávszélességet a virtuális kezelők nem tudják könnyedén megosztani, így a memóriával és a CPU-val minden rendben lehet, de akadályokat hordoz egy olyan erőforrásnál, amelyet nem lehet kezelni, és amikor megpróbálod kijavítani, a régi modell keményen dolgozott volna, nagyobb szervert szerzett, és ilyesmit csinálhat, ez most nagyon egyszerű lehet, csak adjon hozzá egy virtuális tanfolyamot, csak adjon hozzá memóriát a virtuális géphez, és megoldódott. De mi történik, ha a virtuális gép túlzsúfolt kiszolgálón van, és áttelepítésre szorul? Vagy mi történik, ha Ön egy AWS rendszer méretében van, és elérte a maximális méretet, most hová mész?

Tehát ezekkel a problémákkal akkor jár, amikor a környezet most az adatbázis része, egy környezetet csomagol egy adatbázissal, az összes speciális erőforrással, az alkalmazás minden részével, amely a konfiguráció része, a konfiguráció pedig kiszorul. Ez az adatbázis-környezetből származik, sokkal nehezebb kezelni és ellenőrizni.

Ha megnézed, mit csinálnak az adatbázis-központok, akkor már a kezükön ültek, igaz? Elmozdultunk attól az ötlettől, hogy az adatbázisokat és szervereket háziállatokként kezeljük. A kiszolgálóknak vannak neveik, úgy bánsz velük, mintha egyénileg egyedi dolgok lennének, szarvasmarhákkal kezelsz, ez egy állomány kezelése. És az állományok kezelésével az a probléma, hogy ha nem irányítja őket, akkor végül is megrázkódhatnak, és a megbélyegzés nem jó dolog. Jobb ellenőrző eszközökre, jobb módszerekre van szükségünk ezen dolgok kezelésére, és tudnunk kell, hogy mi érintett. A régi modellben könnyebb volt, mert az operátorok és az összes vezérlőrendszer elmondta neked, de ha a kiszolgáló neve UPC-kód, nehéz nehezen kitalálni a dolgokat.

Nem engedheti meg magának a hamis riasztásokat, nem engedheti meg magának olyan dolgokat, amelyek azt mondják: „Probléma van ezzel a gépen, és hogy a gép 30 adatbázist tárol.” Nem engedheti meg magának, hogy a dolgok ne adjanak előzményeket. A figyelőkonzolok nagyszerűek, ha világítanak, de ha a piros lámpa ismét zöldre vált, és nem tudja miért, és nincs története, visszamenjen, hogy megvizsgálja, mi vezetett ehhez, és mi a a helyzet volt, bajban vagy. Szükségünk van olyan rendszerekre, amelyek felügyelnek számunkra, jobb megfigyelésre van szükségünk, azokra az áttételes szakaszos problémákra, amelyek fenntartják az adattörténetet.

Jobb dolgok és egyszerű metrikai küszöbértékek, amelyek megkapják a legfontosabb mutatókat, de nem vezetnek bennünket közvetlenül arra, hogy mi a normális, mi a rendellenes és milyen gyakran fordulnak elő ezek a problémák. Amit igazán beszélünk, a felügyeleti környezet és a teljesítmény kezelése kombinációja, és az eladók a kezükön ültek. Nem adtak nekünk jobb eszközöket. Van olyan rendszereink, amelyekben több CPU és memória van, mint tudjuk, mit kell ezzel csinálni, és még mindig támaszkodunk a kézi beavatkozási modellekre, nem állítottuk be a gépet működésbe, hogy irányítson minket, és a problémák pontjához juttasson minket, még nem jutottunk hozzá ehhez az új stílushoz: „Van itt egy probléma, ezt megteheted, hogy kijavíthatod”, vagy „Van egy teljesítményprobléma, valójában ez a specifikus SQL utasítás, itt három dolog, amit tehetne: használja az SQL utasítás kijavításához. ”Heurisztika alkalmazása, gépi tanulási modellek alkalmazása, amelyek megvizsgálják a rendszer használati szokásait a problémák észlelésére és a hamis riasztások elkerülésére. A gép használata annak elvégzéséhez, amit a gép a legjobban végez, a DBA bővítéséhez, vagy annak növeléséhez, aki a teljesítményproblémákkal foglalkozik.

Ez az új mód, szemben a régi stílusgal. Probléma van ezzel az adatbázissal, a dolgok lassúak, ezért új technikákkal, új módszerekkel rendelkezünk, és ezeket alkalmaznunk kellene, és erre indul a piac. Látja, hogy nem csak a nagy szállítókkal, hanem a harmadik féltől származó cégekkel kezd felbukkanni, és ez tükrözi valamit, ami 20 évvel ezelőtt történt, amikor az adatbázis-gyártók nem adtak egyetlen dolgot a rendszerek kezeléséhez. Szóval ilyen a piac iránya, és ezzel szeretném visszaadni Ericnek.

Eric Kavanagh: Rendben, átadom Deznek. Dez, vedd el, a padló a tied.

Dez Blanchfield: Köszönöm, Mark. Fantasztikus munkát végzett a műszaki alkotóelem lefedésével. Kissé más szemszögből fogom rávilágítani, hogy kiemeljem, mi történt a világ többi részén, amennyire a vállalkozásokra és az őket körülvevő adatbázisokra gyakorolt ​​hatás befolyásolja. Hadd ugorjak az első diára.

A dolgok műszaki és fejlesztői oldaláról, amit éppen fedeztek, látom, hogy a vállalkozásoknak szembe kell nézniük különösen az adatok és az adatbázisok kihívásaival, és nyilvánvalóan megváltozott ez a jelentős lépés a ez a nagy adat fogalma, de az adatbázisok továbbra is annak a szíve és lelke, ahol a szervezetek megőrzik üzleti információikat, és ez a bejárati ajtótól egészen a hátsó irodáig terjed. A szervezet minden részét valamilyen adatbázis érinti, és egy adatbázis táplálja, és nagyon ritkán veszek részt projektbeszélgetésekben vagy valamilyen innovatív stratégiai beszélgetésben egy szervezetben, ahol az adatbázis vagy az adatbázisrendszer témája nem jön fel, és mindig felmerül a kérdés, hogy milyen típusú dolgokat hallottunk az éppen a teljesítményről és a biztonságról, és hogy a fejlesztés miként közelíti meg ezt a kihívást, és hol illenek az adatbázisok, és mi ismerjük a környezetet és az alkalmazást környezetek beszélgetnek, mi van az eszközökkel és a mobilitással?

Még mindig nagyon-nagyon forró téma, és hosszú-hosszú idő óta foglalkozik a dolgok nagy rendszerével, amennyire a modern technológia megy. Ennél a pontnál azt hiszem, hogy tény, hogy szinte mindent, amit a mindennapi életünkben, a mindennapi életünkben megteszünk, azaz az, amelyet most valamilyen adatbázis támogat. Amikor gondolkodunk a körülöttünk lévő dolgokról, legyen szó akár egy számláról, amelyet minden nap postai úton érkeznek valamilyen vásárolt szolgáltatásért, azt elkerülhetetlenül egy olyan adatbázis nyomtatja ki, amely egy adatbázishoz beszél, és ott vagyunk. Telefonjainkban adatbázisok találhatók a névjegyekkel és a hívásnaplókkal, valamint egyéb dolgokkal.

Bárhová is megyünk, a beszélgetés és az általunk használt rendszerek mögött van valamilyen adatbázis, és többnyire meglehetősen átláthatóak számunkra, de az a tény, hogy ott vannak. Tehát azt hittem, hogy gyorsan meg fogom fedezni, miért vált ez nagyon rövid időn belül kérdéssé. A kezdetben az adatbázis fogalma e kedves úriembertől, Edgar Coddtól származik. Míg az IBM-nél dolgozott, megváltoztatta a világot az adatkezelés terén, létrehozva egy koncepciót, amelyet most relációs adatbázisnak nevezünk.

Az elején az adatbázis egy adatbázis volt, és az élet jó volt, meglehetősen egyértelmű volt mind oszlopokban, mind hivatkozásokban és így tovább, a táblázatokban, a szoftverek fejlesztésében pedig elég egyszerű volt, és a teljesítmény valójában nem volt olyan nagy kérdés - új izgalmas technológia volt. Az adatbázisokhoz valamilyen terminálon keresztül jutottunk el, és csak annyit lehet pusztítani, ha egy nagygépen lévő 3270 terminál végén van, és mindig más típusú terminálokhoz, ezekhez a többi rendszerekhez. És a legtöbb esetben a régi stílusú terminálok nagyon hasonlítottak a webes környezetekhez, vagyis az, hogy kitöltsön egy űrlapot a terminál képernyőjén, és nyomja meg az Enter billentyűt, és ki tudná menni, akkor ez mint egy csomag, mint kérés, és a háttérrendszer foglalkozik vele. Alapvetően ez történik egy böngészőben manapság, amikor beír egy linket egy böngészőbe, és ez az űrlap általában nem valós időben tér vissza a rendszerhez, bár manapság az AJAX esetében ez nem teljesen a ügy.

De akkor történt valami, megérkezett a jövő, és nemrégiben az internet, majdnem tegnap egy sec web 2.0-ban és a sarkon, megvan a tárgyak internete. És a jövőbeli folyamatban az adatbázis világa éppen felrobbant, és az adatbázisokkal való interakció csak olyan dologgá vált, amit alapértelmezésben mindannyian megtettünk, nem volt olyan eset, hogy valahova elmegy valamit megtenni, például vásárolni jegyet repülőgépre, és a bolygó másik oldalára akar utazni, valakinek be kellett írnia az összes adatot a terminálba, be kell lépnie egy adatbázisba és ki kell nyomtatnia egy jegyet.

Szinte mindent, amit most csinálunk, függetlenül attól, hogy a Google kabinját jelöljük-e egy alkalmazással, ugrik-e az internetes banki szolgáltatásokra, mindent, amit napi szinten teszünk, valamiféle rendszerrel, adatbázis-alapú. És amikor az internet eljött, ezt egy kicsit könnyebb eljuttatni hozzánk, mindennapi életünket webböngészőn keresztül, majd a web 2.0 jött létre, és a dolgok mobilizálódtak, és a dolgok mérete csak felrobbant. Valójában a témám kedvenc vonalom az, hogy „Az internet mindent összekapcsolt, a web 2.0 mobilitássá és szociálisvá tette, és a dolgok nagyon-nagyon nagyok lettek, és most megvan az internet és a dolgok, és IoT… Yikes !!” Még nem kezdtük el elképzelni, hogy a tárgyak internete milyen hatással van a világra az adatbázis-rendszerekre.

Tehát modern értelemben a terminálként való gondolkodás ténylegesen ezekké vált: mobiltelefonok, különféle típusú táblagépek, akár személyes fogyasztói, akár vállalati szintű nagyképernyős táblagépek, laptopok és a hagyományos asztali számítógépek. valamilyen formában. Ebben a képen láthatja a felület szinte minden formáját, amelyet most az adatbázis-rendszerekkel és az általuk táplált alkalmazásokkal beszélgetünk, a kezünkben lévő apró eszközökktől, amelyek körül járnak, és úgy tűnik, hogy ragaszkodunk hozzájuk, a kissé nagyobb verziókig, az iPad-ekhez és más tablettákhoz, valamint a Microsoft felületeihez, a mindennapi laptopokhoz, amelyek mindig a professzionális környezetben fordulnak elő és így tovább. Az emberek hajlamosak laptopra, nem pedig fix asztalra jutni, ám véleményem szerint ők a modern terminál, és annak egyik oka, hogy az adatbázisok mindenféle kihívással szembesülnek életünk menedzsmentteljesítményének részén, és nem csak a fejlesztésen.

Tehát azt gondolom, hogy ez az egyik legnagyobb kihívás, amellyel a vállalkozások napi szinten továbbra is szembesülnek. Mindenki úgy gondolta, hogy az adatbázisok kizárólagos problémánk, ők nem. Szóval mi az a felkelés? Nos, amikor az egyik végétől a másikig minden, az adatbázisokkal kapcsolatos dolgot, kereskedelmi értelemben vettük át, és a Mark műszaki elemeit nagyon-nagyon jól lefedtük, de kereskedelmi értelemben, mint szervezet, az adatbázisokra gondolunk. Az alapvető tervezési és fejlesztési elemektől kezdve egészen dolgokkal foglalkozunk. Amikor egy vállalkozás elindul, gondolkodni fog az alkalmazások fejlesztésén, a képességek fejlesztésén, vagy akár meglévő alkalmazások valamilyen formában történő megvalósításán. A tervezésnek és a fejlesztésnek valamilyen formáját meg kell valósítani, és nagy figyelmet kell fordítani arra, hogy ezeket az adatbázis-rendszereket hogyan valósítsák meg, támogassák és kezeljék, valamint a teljesítményeket nyomon kövessék és így tovább.

Az adatbázis-környezet és az alkalmazások integrálása, valamint az API-típusok, a hozzáférés típusa, amelyet jelenleg nyújtanak, egyre nagyobb kihívásokkal és bonyolultabbá válnak. A napi adminisztráció, a támogatás és a biztonsági mentések ismét ezeket a dolgokat gondoltuk megoldottnak, ám hirtelen a skála sokkal nagyobb lett, a dolgok gyorsabban mozogtak, és a kötet sokkal nagyobb; a környezet nagyságának, az adatbázis-rendszereknek támogatniuk kellett a tranzakciók mozgásának sebességét.

Gondolj egy adatbázisra egy nagyon, nagyon magas frekvenciájú kereskedési környezetben; az embereknek nincs módja annak nyomon követésére, ez csak egy gépcsoport, amely harcol egy másik gépcsoporttal, hogy nagyfrekvenciás kereskedelmet, vételt és eladást végezzen, és a amelyek ezek a tranzakciók történnek. Gondolj egy olyan modern forgatókönyvre, mint például egy Netflix film korai megjelenése, ahol nem csupán a százakról vagy ezrekről, vagy akár százezrekről beszél, potenciálisan olyan emberek millióiról, akik azt a filmet szeretnék látni már a megjelenés pillanatától. Az összes információt adatbázis-platformon rögzítik, nyomon követik, naplózják és elemezik.

És akkor ott van a folyamatosan működő világ, amelyben most élünk, 24 órán keresztül, és nem csak a Napot követi, hanem mindig éjfélkor valaki fel akarja tenni valamit, és az üzleti órák a világ minden táján követik a Napot. Tehát az üzemidő és a rendelkezésre állás alapértelmezés szerint éghajlat, mivel az üzemzavar valójában egyszerűen nem elfogadható. És a redundancia, ha teljesítményprobléma merül fel, vagy ha frissítéshez vagy javításhoz, vagy biztonsághoz van szükség karbantartási ablakra, valóban képesnek kell lennünk arra, hogy átvágjunk az egyik adatbázis-környezetről a másikra, és zökkenőmentesen és automatikusan elvégezzük.

Biztonság és szabványok és megfelelés, a késői világban, különösen a GFC-ben, nagyon nagy dolgok történtek, és így egy sor új kihívással kell szembenéznünk a megfelelés, a biztonság és a megfelelő szabványok körül, és szükségünk van hogy valós időben és ideális esetben műszerfal formában tudjon jelentést készíteni ezekről. Nem akarjuk, hogy majmok csapatát küldje ki egy adatközpontba, amely megpróbálja megtalálni a dolgokat, szükségünk van a rendszerre, hogy ezt azonnal, valós időben elmondja.

És a két nagy móka közül, amiről szinte senki sem beszél, általában a szőnyeg alá toljuk őket, és reméljük, hogy soha nem emelik fel csúnya fejüket, hanem a katasztrófa utáni helyreállítást és az üzleti folytonosságot - ezek is olyan dolgok, amelyeknek kellene leginkább automatikusan történik, ha erre szükség van.

Napokat tölthetnénk azzal, hogy megbeszéljük azokat a dolgokat, amelyek bajba kerülhetnek az adatbázis-környezetekben, és amelyekre általában az emberek reagáltak, de most rendszerekre és eszközökre van szükségünk, hogy ezt meg tudjuk tenni. Az egyik példa az adatsértés, és amikor adatbázisokra gondolunk, ezt a kérdést meglehetősen nyíltan felteszem, különféle formákban: mi történik az adatbázisokkal, ha szemünket vesszük a labdától, és valami kritikus rosszul fordul? Különösen akkor, ha nincs olyan rendszer, amely figyeli a teljesítményt és a biztonságot, valamint az adatbázisok futásának egyéb főbb szempontjait.

Nos, ami megtörténhet, ez egy képernyőkép az elmúlt két-három évben a közelmúltban elkövetett néhány megsértésről. Mindig ezek mind egy adatbázis-rendszerből származnak, és mindig is merültek fel valamilyen probléma a biztonságban vagy a vezérlésben vagy a hozzáférésben, és a bal felső sarokban 152 millió Adobe-fiókot tekintünk, ahol minden részlet található az ügyfelek száma megsértésre került. És ha esetleg megfelelő eszközök álltak volna rendelkezésre az esemény nyomon követésére és rögzítésére, valamint a biztonság ellenőrzésére, valószínűleg elkerüljük ezeket a néhányat, az ellopott első százszáz feljegyzés riaszthatott bennünket, és leállította a következő százötvenmilliót.

Aztán eljutunk az egész út kulcsfontosságú pontjához, átvitt minket, azaz: miért van szükségünk jobb rendszerekre? Miért nem dobhatunk több testet erre a dologra, hogy véleményem szerint jól és valóban átléptük a csúcspontot, és minden bizonnyal azt hiszem, hogy van egy olyan eset, amely későn bizonyult, hogy több DBA-t, adminisztrátort és több embert dobtak a ez a dolog nem oldja meg a problémát. Jobb eszközkészletre és jobb rendszerekre van szükségünk.

Az alábbiakban bemutatjuk az öt legfontosabb okomat, amelyek véleményem szerint ezt támogatják, és fontossági sorrendbe vannak sorolva, az alapján, amit látok ezekben a magánvállalkozásokban és államokban, amelyek irányított környezetet mutatnak, és milyen kihívásokkal szembesülnek az adatbázis-környezetek, és kezelni őket.

Biztonság és megfelelés - első számú. Tudod, hogy ellenőrizheted, hogy kinek van hozzáférése, hol van hozzáférése, mikor van hozzáférése, mennyi időnként férnek hozzá, ahonnan férnek hozzá. Potenciálisan azok az eszközök, amelyekhez ténylegesen megérintettek, és azok a fajta dolgok, amelyeket megnéztek, és a megfelelőség, amely körül jár. Ha az emberek 30 nappal később jelentéseket készítenek, hogy megmondják, vajon a dolgok rendben vannak, már nem megfelelő, valós időben kell történnie.

Teljesítmény és monitorozás - úgy tűnik, hogy nincs brainer, de mindig nem. Függetlenül attól, hogy nyílt forráskódú eszközöket vagy harmadik féltől származó kereskedelmi eszközöket használunk, mindig is sok szempontból elmulasztottuk a hajót, a szükséges teljesítményfigyelés típusaival, valamint a szükséges részletekkel és az időben történő reagálás képességével. .

Események észlelése és reagálás - azonnali, valós idejű dolgoknak kell lennie, és mindig szükségünk van egy rendszerre, amely elvégzi nekünk, vagy legalábbis riasztást küld nekünk, hogy megbirkózzunk vele, hogy a felmerülő néhány kérdéssel foglalkozzunk. gyorsan, és ne lépcsőzetesen ellenőrizhetetlenné tegye.

Menedzsment és adminisztráció - ismét úgy gondoljuk, hogy ezek a problémák megoldódtak, nem így vannak. A cél az, hogy az adatbázis-csapatok, különösen a DBA-k, amelyekkel egy rendszernek gondoskodnia kell a dolgokról, még nem oldották meg ezt a problémát, ez még mindig egy igazi dolog.

És közvetlenül a tervezés és fejlesztés elején, amikor elkezdjük ezeket az eszközöket, felépítjük az adatbázis-környezeteket, képesek vagyunk a megfelelő eszközök kidolgozására a fejlesztéshez és teszteléshez, valamint az integrációhoz, a platformokhoz. Ezt még mindig nem könnyű megtennünk, és ez az egész utazás ugyanolyan üzenetre vezet minket, hogy véleményem szerint jobb rendszerekre és jobb eszközökre van szükségünk ahhoz, hogy elérjük a szükséges eredményeket. adatbázis-környezetünk, tehát azok a vállalkozások, amelyek növelik az ügyfelek értékét. Nem hagyhatjuk csak több test és további DBA dobását, a skála túl nagy, a sebesség túl gyors és a hangerő túl magas. Ezzel visszaadhatom neked Eric-t.

Eric Kavanagh: Nagyon szeretem, rengeteg talajt takarunk az embereknek, sok leendő vezetést, és megyünk előre, és csak egy másodperc alatt átadjuk a kulcsokat Bullettnek.

Bullett Manale: Jól van.

Eric Kavanagh: Ó, vedd el és Bullett, most átadom neked, és a padló a tied.

Bullett Manale: Rendben, köszönöm. Azt hiszem, sok jó pontot tettünk. Csak egy pillanatra akartam gyorsan beszélni Ideráról, hogy kik vagyunk, majd beugrunk. Be fogok beszélni arról az eszközről, amelyről úgy gondolom, hogy sok ilyen cuccról beszélünk, egyfajta készlet és fajta vita néhány olyan területről, ahol ezek az eszközhöz igazítják a Diagnostic Manager terméket.

Most, amit először meg akarok csinálni, az csak egyfajta háttér-hátteret ad neked arról, hogy ki az Idera; 2003 óta működünk, és így csak az SQL Server eszközökkel kezdtük el, és erre fogunk ma összpontosítani, az lenne a Diagnostic Manager termék. De láthatja az összes vödör dolgot, amelyek itt vannak, és a közelmúltban, amint azt már korábban említettük, megszereztük a Precise-t és az akvizíción keresztül az Embarcadero is van, és így van egy nagyon jó termékportfóliónk.

A teljesítményfigyelés szempontjából az SQL Server szempontjából az a termék, amelyről beszélni akarok, és amely összehangolja ezeket a témákat, amelyeket tárgyalunk, a Diagnostic Manager. Ez egy olyan termék, amely már az Idera napja eleje óta meglehetősen jó, és szerencsés vagyok, hogy 2005-ben kb. 2005 óta részt vehetek benne. És sok változást láttam a SQL Server, a fizikai helyett a virtuálisra vált, minden olyan cucc, ami történt, és a DBA-k igényei is, ahogy a környezet növekszik, és az ilyen típusú dolgok.

Amit elkezdtem, a termékünk tipikus felhasználója a DBA, és tehát amikor először beszélünk emberekkel, potenciális ügyfelekkel, akkor inkább a DBA-kkal beszélünk. Nem beszélünk az informatikai vezetőkkel vagy az igazgatókkal, ez egy bizonyos ponton elérheti ezt a szintet, de a kezdeti kezdet az, hogy a DBA-nak problémája van, a DBA megpróbálja kijavítani a problémát, és sokszor Elkíséreljük letölteni és kipróbálni a terméket ennek részeként. Megkaphatja az adatkezelőt, vagy a DBA-t, vagy az eljáró DBA-t, az a fickó, akinek szerencséje van, hogy bizonyos esetekben a leg technikaibb a szobában. Most, amikor egy nagyobb vállalati környezetbe jut, nyilvánvalóan megkapja a teljes értékű DBA-kat, általában ezek lesznek az eszközzel. És előrementem, és csak egy kis szócikkkel egészítettem ide a Wikipédia. Ez a fajta megy át a DBA felelősségi körébe, ahogy a Wikipedia mondja, ezt csinálják.

Ha itt áttekinti a felsorolást, sok ilyen dolgot nem fogok elolvasni, de sok tipikus dolgot megkapsz, amire gondolnád, majd az egyiküknél megfigyelést végeztek. és az adatbázis teljesítményének optimalizálása, és ez elég nagy. És ami érdekes, az, hogy amikor beszélsz a DBA-val, ők mindig előbb hibáznak, amikor a problémák merülnek fel, és valószínűleg nem az ő hibáik, de ha van teljesítmény-probléma, általában egy olyan alkalmazással, amely egy DBA adatbázishoz van kötve, ők azok, akiket hibáztatnak, tehát mindig keresik azokat az okokat, amelyek nem az ő hibájuk. Sok esetben ezt az eszközt, a Diagnostic Manager programot használhatják fel, hogy segítsenek nekik.

De a nap végén is, ha az adatbázis nem teljesít, akkor ezen egyéb dolgok nagy része nem igazán számít, az alkalmazások nem működnek, akkor ezeknek sok szempontjából nem számít dolgokat. Mindenekelőtt azt akarjuk tudni biztosítani, hogy a felhasználói élmény, ahogy azt mi ismerjük, ne csökkenjen, ez olyan dolog, amelyre a DBA-k mindig törekszenek. És azt hiszem, hogy ha megnézi azokat az okokat, amelyek miatt az emberek általában megvásárolják és használják az SQL Diagnostic Manager terméket, akkor az egyik első ok, valószínűleg nem a legfontosabb, nem utoljára vagy a legkevésbé, de ez mindenütt egyenlő, és attól függően, hogy kivel beszélsz, ezek az okok szinte egy vagy kettő mindig fennállnak, valamilyen szükség van rá.

De az első csak az, hogy a példányok központosított nézete SQL-ként is működik, amelyeket kezeli. És a vicces dolog az, hogy sok esetben, ha a DBA-val kérdezik: „Hány példányt kezzel?” A szám oly gyakran változik, hogy bizonyos esetekben nem igazán biztosak. Szüksége van tehát többre, mint arra, hogy mindent fel tudjon vetíteni a képernyőre. Meg akarja ragadni ezt az információt, meg akarja érteni azt, és tehát ez az egyik dolog, amelyben a Diagnostic Manager határozottan segíthet, az, hogy képes legyen Önnek ilyen képet nyújtani a környezetről.

És ez nem csak a környezetbe való betekintés, hanem az a nézet is, amelyet a DBA, az adatbázis-adminisztrátor kényelmesen alkalmaz, és ez egy konzol, amely DBA-központú, ha akarod. Adatbázis-rendszergazda számára készült. Rengeteg figyelőeszköz található odakint, rengeteg teljesítményszerszám van odakint, de mint mondtam, a nap végén a DBA egy olyan eszközt akar, amelyet egy DBA-nak terveztek, mert nagyon sok olyan dolog van, ami specifikus napról napra.

És ezzel együtt: megvan a SCOM, megvan a HPF, megvan az összes többi technológia, de azt akarják, hogy valami különlegessé váljon azzal, amit csinálnak. Úgy gondolom, hogy tudunk segíteni ezen a területen ezzel a termékkel, látni fogja, amikor egy másodperc múlva belejutunk hozzá. A másik dolog, amelyet látunk a DBA-val, és amely határozottan az egyik dolog, amelyre korábban is megérkeztünk, az, hogy képeseknek kell lenniük látni, hogy mi folyik, és képeseknek kell lenniük az egész vállalkozás áttekintésére és nyugodj meg, ha tudod, mi történik. De ugyanakkor nem ülnek ott, és a konzolokra bámulnak.

Emlékszel azokra a golyópontokra, amelyeket láttál a listán, amelyeket éppen összehúztam? Ezeket a többi dolgot is meg kell tenniük, tehát nemcsak a tüzek várására kell várni. Sok esetben találkozók lesznek, vagy az adatbázis-adminisztrátorral kapcsolatos karbantartási ablakok egy része éjszaka közepén fut, amikor alszik, így képeseknek kell lenniük visszamenni és megnézni, mi történt . Sok esetben, ha nem észlel valamit, amikor ez történik, miután a probléma megszűnt, vagy legalábbis az SQL Server-rel, ez olyan kérdéssé válik, ahol olyan helyzettel foglalkozik, ahol nem már vannak ennek a problémának a maradványai. És ezek a problémák megszűnnek, és csakúgy, mint a maradványok, ami azt jelenti, hogy kevesebb hibaelhárításra van szüksége, kevesebb információval kell dolgozni.

Mindezek mellett határozottan az egyik dolog, amellyel a Diagnostic Manager segíthet, az, hogy megadja neked a múltbeli nézetet, hogy megkérdezze a múltbeli információkat: „Volt riasztás a blokkolással kapcsolatban, van-e problémám a blokkolásról, voltak-e olyan dolgok, amelyek történtek az erőforrásaink vonatkozásában? ”Vissza tudok térni és lekérdezni ezeket az információkat. Tudok pontos időpontokat kidolgozni. Ezeket a dolgokat közvetlenül az eszközön belül megtehetem.

Mindezen dolgokat, annak ellenére, hogy belső vagy külső alkalmazásokról van-e szó, a DBA tudni akarja, mert látni akarják, mi okozza a problémát. Nem igazán számít, valakit a szervezet belsejében vagy a szervezeten kívül valaki írta-e a kód; továbbra is szeretnék elkülöníteni, hogy tudják, hogy a probléma megtörténik, és tudják, honnan származik.

Tehát a teljesítmény és az elszámoltathatóság kulcsfontosságú része annak, amit termékünk tesz. Biztosíthatjuk ezeket a részleteket, és ami nagyon kedves, az, hogy meg tudja-e fúrni. Ha szűk keresztmetszet áll fenn, összekapcsolhatja azt az alkalmazás, a felhasználó, az adatbázis és a lekérdezés között. És ismét, ez egyfajta dohányzó pisztoly. Közvetlen összefüggést kap a keresés futtatása között, mit csinál? És nemcsak a lekérdezésről szól, az önmagában történő végrehajtás szempontjából, hanem az is, hogy a lekérdezés idővel rosszabbodik? És ezekre a dolgokra is meg lehet válaszolni, a termékkel, ami határozottan olyasmi, amit ha proaktívan próbálsz, örülök, hogy azt mondhatom: "Hé, itt van egy lekérdezés, amely rosszul futott, de fiú nézd meg amint tovább halad, láthatjuk, hogy még rosszabbá is fut, meg tudok csinálni valamit erről. "

Ha itt megyünk a következő területre; és ez valószínűleg - azt mondanám, hogy ez az egyik nagy. Az egyik kérdés, amelyet felteszek a termék bemutatásakor, mindig felteszi a kérdést az adatbázis adminisztrátorának: "Hogyan hall az SQL Server adatbázisaival kapcsolatos problémáról?" És nagyon vicces, mert az idő nagy részében - most már megadva - általában a termékeinket nézik, mert sok esetben megpróbálják megoldani egy adott igényt. De érdekes hallani a kezdeti dolgot - legalábbis az SQL Servernél, hogy ez volt a fajta - tudod, az SQL Server kezdeti napjaiban volt SQL Server, majd Oracle. És mindenkinek volt Oracle, és az SQL Server olyan volt, mint a jobb kifejezés hiánya miatt az adatbázisok vörös hajú mostohalánya, az első induláskor.

És amikor a Microsoft további funkciókat adott hozzá, egy kicsit vállalati eszközré vált. És nyilvánvalóan azóta hosszú utat sikerült elérni. De a lényeg az, hogy egyszer elmondhatná, hogy az adatbázisokat a nap folyamán nem tekintették kritikusnak. És ez az idő múlásával megváltozott. Ezért sok esetben az emberek megpróbálják körülfogni a kezüket, és azt mondják: „Tudod mit? Megvan az összes ilyen SQL Server adatbázis, megpróbálom megbirkózni vele. "Ahelyett, hogy a help desk problémáiról vagy az egyes emberek problémáiról hallottam volna, amelyek - mint maguk a felhasználók, keresnek néhány módot, hogy ezt megkerüljék: olyan módszereket keresnek, amelyekkel tudatosítani tudják ezeket a helyzeteket, még mielőtt azok megtörténnének.

És tehát a Diagnostic Managerrel ez az egyik dolog, amit meg is próbálunk tenni, legalábbis képes arra, hogy a DBA először tudjon ezekről a helyzetekről vagy azokról a problémákról, hogy meg tudják csinálni valamit róla, akár akkor, amikor azok történnek, akár még egy lépéssel tovább is elemezheti ezeket a rendszereket, amelyeket figyeli. És hogy proaktív tanácsokat adjunk Önnek, amelyek javítják az adott példány teljesítményét, és rendszeresen meg tudjuk csinálni. Például hozzá kell adnunk egy indexet a munkaterhelés alapján; az ilyen típusú dolgokat, az eszközöket, amelyek szintén képesek. Tehát ezt sok látni fogjuk az eszközben.

A másik dolog, és az utolsó dolog, amely szerepel a listán, ez inkább általános leírás, de ez mindenképpen érdemes megjegyezni. És különösen, amikor nagyobb vállalati szintű helyzetekbe kerül, ahol sok példány van, mindig lesz valami homályos dolog, amelyet figyelni akarok, ha az adatbázis adminisztrátor vagyok. példa. Tehát azt próbáljuk előre jelezni, hogy a tipikus DBA-t mi figyelni fogja.

Ha ezt mondják, akkor szintén képes leszel: mindig lesz valami új. Tehát biztosítottuk a módját, amellyel felveheti azokat a mutatókat, amelyekre figyelemmel kell kísérnie és kezelnie kell a telepítési pont hozzáadása után. Tehát minden PerfMon számláló, WMI számláló, SQL Server számláló objektum; mindazok beépíthetők az eszközbe. Lehetséges további lekérdezések hozzáadása, amelyek beépíthetők a szavazási intervallumokba.

És utoljára érdemes megjegyezni, hogy hozzáadhatunk és valóban kommunikálhatunk mind a vCenterrel, mind a Hyper-V-vel, hogy a metrikákat ki tudjuk vonni a környezetből. Mivel az egyik dolog, amelyet a DBA-val azonosítottunk, az, hogy általában nem részei kifejezetten a műveleteknek. És nem feltétlenül áll rendelkezésükre számukra a vCenter környezet, vagy az elérhető dolgok.

És tehát a probléma az, hogy ha egy SQL Server-példánnyal foglalkoznak, és erőforrásokat kaptak nekik, de ez a példány virtualizálódik, akkor úgy tűnik, hogy a világ minden erőforrással rendelkezik, amikor csak figyeli a vendég operációs rendszeren. A valóság az, hogy a gazdagépen 30, 40, 50 vagy 100 más virtuális gép van, amelyekhez megpróbálnak hozzáférni, és ugyanazokkal az erőforrásokkal állnak rendelkezésükre. És ennek valóban való észlelése az, ha kommunikálunk azokkal a többi környezettel és azokkal az interfészekkel, ebben az esetben, amit mi is teszünk.

Meg tudja adni azokat a más típusú számlálókat az eszközhöz. Most nem csak arról van szó, hogy képes-e megfigyelni ezeket a számlálókat, hanem arról is, hogy képesek-e ezeket az új számlálókat bevezetni a termékbe, hogy azok részévé váljanak az eszközhöz, mintha egy mezőn kívüli mutató lenne. . Egy dobozban lévő dolog, amelyet figyelni szeretne; tehát ez azt jelenti, hogy be lehet építeni őket az irányítópultba. Ez azt jelenti, hogy felvehetjük őket saját egyedi jelentéseibe, képesek nyilvánvalóan beállítani a küszöbértékeket és riasztani őket, de alapbeállíthatjuk őket, és képesek vagyunk bizonyos tudással beállítani a küszöbértékeket arra is, hogy hol állítsuk őket az olyan dolgok alapján, mint az Ön alapvonalak és mi a normális. Tehát nagyon sok ilyen dolog van, amelyek szintén a termékben vannak.

Amit én nekem biztosítottam, az az, amit „a Diagnostic Manager legfontosabb teljesítményeinek” nevezek, és megyek előre, és csak egy kis ízelítőt adhatom neked, ha belépetek a termékbe. ossza meg a képernyőm, oké, és ezt csak áthúzza. Tehát mit fogsz látni, ez a Diagnostic Manager konzolja. És ahogy már korábban említettem, megyünk az első központi szállítmányhoz, és megnézhetjük a vállalkozás szintű nézetből adódóan. Sokféle példa van erre az eszközön belül. Van egyfajta miniatűr nézet; inkább rácsszerű nézet van. A rugalmasság szempontjából van egy web alapú konzol is. A web alapú konzol más nézetekkel is elérhető, mint például a kulcs térképek és hasonló dolgok. De lényeg az, hogy megvan az a képessége, hogy valamilyen módon nézzen meg és lássa a dolgokat. de a problémák felmerülésekor egy kicsit tovább mélyedsz az eszközbe, és valójában megnézed az adott problémát Lems, és valamilyen módon megértheti és tudja, mi folyik itt. És ez nyilvánvalóan nagyon fontos.

Most, hogy valóban megnézhetjük, mi történt a múltban; Ha egy olyan problémára keresem, amely tegnap vagy egy héttel ezelőtt történt, akkor ebben a helyzetben, tudod, szükség lesz arra, hogy képes legyen elmenni az SQL adott példányára. A jó hír az, hogy ha tudja, hogy mikor történt ez a probléma a terméken belül, akkor közvetlenül az előzmények böngészőbe léphet. És meg tudom mutatni egy adott napszakot; lehet néhány héttel ezelőtt, tegnap is. De bármilyen napot választom a naptárban, akkor a különféle szavazási intervallumokkal mutatom be. Ebben az esetben most tényleg látom, mit láttam volna, ha április 20-án, 13: 37-kor néztem volna a konzolt.

Tehát vissza tudok térni az időbe, és ha egyszer megcsinálom, az itt látható különféle lapok tükrözik az adott időpontot, ideértve azokat a lekérdezéseket is, amelyek esetleg rosszul futtak, beleértve talán akkor is, ha Véleményem szerint blokkoltam. Az ilyen jellegű dolgok megjelennek az eszközben, és ez lehetővé teszi számomra, hogy kiaknázzam azt a történeti információt, hogy tudjam-e kijavítani a problémát. Ha most megjegyezzük, hogy amikor a történelemről beszélünk, akkor a másik dolog, amit itt érdemes megjegyezni, az az, hogy nem csak a történelem használatát használja a problémák megoldására. Ez a történelem nyilvánvalóan nagyon értékes más okokból. És az egyik nagy az, hogy képes legyen hatékonyan meghozni a döntéseket, és gyorsan, megfelelő információkkal meghozni a döntéseket. Tehát az egész történelem, az összes információ, amelyet gyűjtünk, beszámolhatunk.

Ha valaki odajön hozzám, és azt mondja: "Megkaptam egy igazán nagyszerű új alkalmazást. Ez meg fogja változtatni a világot, ahogy tudjuk. Ó, egyébként adatbázisra lesz szükség, és hát egyébként valóban rögzíteni fogja a I / O azon a gépen, ahol az adatbázis található. " Ha tudom, hogy belemegyek, akkor kihasználhatom ezt az információt, hogy az összes termelési kiszolgálóm rangsorolását biztosítsam, talán a gyűjtés utolsó hét napja alapján. És nagyon gyorsan meg tudnám következtetni, hogy mely esetekben van a legmegfelelőbb használni az adatbázist. Tehát nyilvánvalóan nagyon értékes is az a fajta történelmi információ.

Maguk a lekérdezések; a lekérdezések szempontjából nagyon sokféle módon meg tudjuk csinálni ezt az eszközben. És amit szeretek nézni, a Query Waits View, mert a Query Waits View nagyon hasznos abban, hogy értékelni tudja. Ha van szűk keresztmetszetem, hogy lényegében azonosítsam az összes különféle területet, amelyek befolyásolják az adott, konkrét lekérdezést; nemcsak magának a lekérdezésnek és annak milyen hatása van, hanem azt is tudja, hogy melyik alkalmazásból jött, mely munkamenetből jött, melyik felhasználó hívta és az összes ilyen anyag, látom, hogy nyilvánvalóan az információk valós időben, de képes vagyok arra is, hogy megvizsgáljam ezeket a múltbeli adatokat. És tehát ez az egyik dolog itt, és elindítottam egy forgatókönyvet, de meg kell várnom, amíg az felbukkan.

Amíg ezt várjuk, szeretnék - és tudom, hogy rövid időnk van, ezért egy kicsit szerettem volna beszélni arról is, hogy a figyelmeztető jelzés proaktív. És amikor ilyen jellegű dolgokról beszél, amint mondtam, a proaktív rész, sok eszköz figyelmeztet. A legfontosabb az, hogy nem küldünk e-mailt. A kemény rész nem az eseménynaplóba ír, vagy az SNMP csapdát nem generálja. A legnehezebb rész tudni, mikor kell a figyelmeztetést a megfelelő időben elküldeni. Tehát ehhez sokat kell számolni, és meg kell értenie: "Mi ez az adott példány esetében, és mi az a normális helyzet, amikor ehhez a példányhoz kapcsolódik?"

És tehát az összes olyan mutatóval, amelyben értelme van erre, alapul vesszük ezeket a mutatókat. Valójában megmutatjuk az alapvonalat, megmutatjuk azt a küszöböt, amelyre jelenleg beállítva. És akkor a másik jó dolog ezzel kapcsolatban, hogy mondjuk, hogy a küszöbértékeimet ebben az esetben hat és tíz értékre állítottam erre a példára. Hat hét múlva, ha visszatérek ehhez a példához, ez az alapvonal teljesen megváltozhat, mivel az alapvető értékek alapjául szolgáló számítás közben az egyik dolog egy gördülő hétnapos számítás. Tehát mindig az alapvonal legfrissebb verzióját adja nekem. És mi történik, ha ez az alapérték felmegy a küszöbemre? Ebben az esetben látom és figyelmeztető javaslatokat láthatok, amelyek alapvetően azt mondják: "Hé, van egy olyan küszöb, amelyet valószínűleg hibásan állítottak be, konkrétan arra a helyre, ahol látjuk a küszöböt, és nyilvánvalóan ott, ahol az alapvonal van, valószínűleg figyelmeztetést kap valamiről, ami normális esemény. "

És így ahelyett, hogy valami tünetét kezelném valami normálisnak, képes vagyok azonosítani azt a helyzetet, amelyben a tényleges küszöbérték helytelen. És amit engem nyilvánvalóan megtehet, az az, hogy a küszöbértékeket beállítom annak alapján, hogy hol kapok riasztást. Tudom, hogy ez inkább cselekvésre ösztönzés és nyomozás, hogy valóban problémát jelent-e. És azt hiszem, hogy az eszköz egy része valóban hasznos a kiindulási helyzet szempontjából, és képes kiszámítani.

Most ezzel a termékkel lehetősége van arra, hogy több alapvonalon rendelkezzen; beállíthatja azokat különféle időszakokra, és dinamikusan beállíthatja a küszöbértékeket az alapvonalak alapján, ami szintén nagyon fontos része az alkalmazkodásnak az SQL Server-példányok napi szintjén bekövetkező változásokhoz. . Most, ebben az esetben itt a fajta küszöbértékek sok beállítását lefedjük, és megmutatjuk az alapvonalakat. Ami a tényleges riasztásokat illeti, maguk az értesítések, a Diagnostic Manager hűvös dolga, az az, hogy több riasztási profilt nyújtanak Önnek. Tehát ha van például egy készenléti profil, amely 2: 00-tól 5: 00-ig tart, akkor van egy profilom, amely éppen arra az időtartamra vonatkozik, és itt beállíthatom az összes feltételt és a megfelelő beállításokat. a válaszomért.

A válasz szempontjából az a kérdés, hogy bizonyos esetekben igen, küldhetek e-mailt, vagy el tudok készíteni SNMP-csapdát, vagy írni az eseménynaplóba. Sok más dolgot megtehetünk, de amint a DBA-kkal beszélek, az igazán szereti az a tény, hogy az elvégzett munka nagy része a legtöbb esetben ismétlődő dolog. Olyan cucc, hogy pontosan tudják, mikor jelentkezik a probléma, mit kell tenni annak kijavításához. Csak el kell menni és beavatkozni. És ahogy növekszik a környezetük, és mivel több példány van, ez sokkal nehezebb megtenni. Tehát az eszközön belül elvégezhető egyik olyan dolog, amelyet véleményem szerint érdemes megjegyezni: az, hogy képes-e egy feltételt felállítani, de ennek a feltételnek a alapján képes beállítani egy választ a parancsfájl futtatásához, a job, egy futtatható fájl futtatásához. És az a lényeg, hogy ha úgy dönt, hogy futtat egy szkriptet, akkor használhatok paramétereket annak a szkriptnek a belsejében, amely futásidejű lesz, és kitölti a tényleges információkat.

Tehát, ha problémák merülnek fel egy adott adatbázissal, a szkriptet úgy tervezik, hogy csak az adatbázis ellen futtassa, ahol a probléma merül fel. Tehát dinamikusan meg lehet oldani a kérdéseket automatizált módon, és akkor is kapok e-mailt, hogy visszatérjek és elmondják nekem, hogy "Hé, volt egy probléma, de egyébként, kijavították." A forgatókönyvet futtatta, és mint a DBA, tud róla, de valójában nem kellett bemenned és beavatkoznia. Most, ugyanazon a proaktívakról szóló megjegyzés mellett, nyilvánvalóan itt van még egy funkciónk, az „Elemzés”. És ezt megteszi, rendszeresen ellenőrzi az SQL példányát. És bizonyos esetekben mélyebben belemerül a keresetbe. A hipotetikus index elemzését elvégezzük. Felvehetek egy indexet? Távolíthatom el az indexet? És mindezen dolgok nyilvánvalóan segítenek az előadásomban, de ismét az egész proaktív jellegű. Arról szól, hogy döntéseket tudunk hozni, mielőtt a cucc szünetet tart, és hogy jobban futhassunk. És tehát sok esetben valóban erre törekszünk.

Visszatérve a Query Waits-hez, amelyről korábban beszéltünk; mint láthatja, van egy nagy tüske itt. Korábban futtattam egy forgatókönyvet, amely csak várakozási tevékenységet okozott, és amint már említettem, van egy igazán egyedi módszer, amellyel ezeket az információkat kimerítheti. Ha meg akarom nézni, hogy milyen alkalmazás volt; Látom, hogy a NoSQL alkalmazásból származik. Láthatnánk az ahhoz kapcsolódó adatbázist, a munkamenetet, a felhasználót, és ha akarom, ezt a várakozásaim szempontjából is rangsorolhatom. Tehát, elmondhatom, az összes várakozásról, amelyek abban az időablakban zajlottak, melyik történt a legjobban? És ha látom, hogy amikor ez történt a legjobban, akkor az nagyon jó dolog, hogy bele tudok fúrni ezt a várakozástípust és látom az összes parancsot. Ha itt nézel, akkor a várakozás történt. És elsősorban azt is látom, hogy mely alkalmazás volt, ami miatt a várakozás megtörtént.

Tehát úgy tűnik ki, mint egy fájó hüvelykujj. Azonnal elmehetek és mondhatom: "Ez az alkalmazás okozza a szűk keresztmetszetet. Most mi volt a lekérdezés, amelyet futtattak? Melyik felhasználó futtatta? Melyik adatbázishoz futott?" És így tovább. Tehát remélem, hogy van értelme, és az is segít abban, hogy megbizonyosodjon arról, hogy nincs-e késése a környezetében, mivel az az adatbázisaival kapcsolatos. Remélhetőleg ez hasznos. Ezen a ponton megyek előre, és továbbadom, és azt hiszem onnan folytathatjuk.

Eric Kavanagh: Persze. Tehát azt hiszem, csak a nap szakértőinek dobom. Mark, először talán kommentálsz és feltesz egy pár kérdést. Akkor Dez, bekapcsolhat.

Mark Madsen: Igen, köszönöm, nagyon élveztem ennek nézését. Sokkal intelligensebb monitorozás, mint szoktam látni. Kíváncsi vagyok az ennek hátterében álló adatok kezelésére; a nyomon követhető mutatók kezelése, és tudod, hogy olyan dolgokat kell keresni, mint például az alapvonalak eltolása, amely az egyik kedvenc fájdalompontom a műszerfalakkal. Hogyan kezeli ezeket az adatokat, és annak második része, tudod, a kiindulási mutatókkal, mint például egyfajta eltolás - képes-e megváltoztatni a küszöböt is automatikusan, hogy nekem ne kelljen menjen vissza, és kézzel állítsa vissza a küszöbértékeket, amikor az alapérték eltolódik?

Bullett Manale: Igen, igen, és az a jó dolog, hogy dönthet úgy. Megteheted akár. Beállíthatom a küszöböt, és statikus beállítást is beállíthatom, vagy bejelölhetem a jelölőnégyzetet, hogy „Dinamikus küszöböt csinálj, amely megváltozik az alapvonalaim változásakor.” És képesek vagyok az eszközzel beállítani az alapértelmezett ablakot de ha erre szükségem van, akkor lehet, hogy van egy külön alapvonalam például a karbantartási ablaktól 2:00 órától kezdve, mondjuk mondjuk 5:00 óráig, mert adót fogok adóztatni CPU, a meghajtóim és minden más, mert akkor végezzük el az összes karbantartást.Ez akkor automatikusan, ha ezt választanám, automatikusan beállítja a küszöbértékeimet, hogy azon kívül legyenek, ahol kívül esik, ami normális azokhoz a mutatókhoz, amelyek Úgy döntök, hogy ezt csinálom. Ez lehetővé tenné számomra. Alapvetően az eszközben képes beállítani az időablakokat, azaz a kiindulási ablakokat, és minden ablakot külön entitásként lehet kezelni a dinamikus alapvonal-beállítás, amit meg lehet tenni, és annyi ablakot adhat hozzá az alapvonalhoz, mint yo akkor kell, ha ennek van értelme. Lehet, hogy van egy hétvégi ablaka, egy hétköznap munkaidőben, egy karbantartási ablak, amely éjszaka közepén történik, és így tovább, és így tovább.

Mark Madsen: Köszönöm.

Bullett Manale: Azt hiszem, visszatérve a kérdés első részéhez, megvan, és összegyűjtjük ezeket az információkat. Nem igazán beszéltünk az építészetről, de van egy háttér-adattár, amely teljes ellenőrzést gyakorol az adatok megőrzése felett, de van egy olyan szolgáltatásunk, amely az éjszaka közepén fut, és megy, és az összes alapvető számításunkat, és ezeket az adatokat összegyűjti, összegyűjti és értelmezi azokat. És nyilvánvaló, hogy ezzel párhuzamosan számos jelentése van, amelyeket felhasználhatunk az alapvonalakkal szemben, konkrét mutatókhoz. És még összehasonlíthatja ugyanazon kiszolgáló alapvonalait, ugyanazon mutatóval, különböző időtartamokra. Láthatja, vannak-e különbségek, amelyek megtörténtek, vagy mi a delta. Sok ilyen típusú lehetőség is létezik.

Eric Kavanagh: Dez.

Dez Blanchfield: Egy gyors kérdésem van számomra - széles spektrumban van, mit tehet ez az eszköz. Most a fejlesztés korai szakaszában tapasztalja annak használatát, vagy továbbra is elsősorban termelési környezetvédelmi eszköz? Más szavakkal: a fejlesztők hozzáférést kapnak-e és használják-e a korai fejlesztésük során, majd tesztelik az integrációs fázist? Vagy még mindig elsősorban termelési környezetben használják?

Bullett Manale: Azt mondanám, hogy a legtöbb alkalommal, amikor a termelési környezetben látjuk. A helyzetektől függ, de nagyrészt azt mondanám, hogy elsősorban a termelést és mi - és ez is, tudod, igazságos megemlíteni, hogy a dev- és a tesztkörnyezetben eltérő árakat alkalmazunk, tehát egy kicsit vonzóbb. Látjuk, hogy az emberek ezeket a környezeteket használják, de azt mondanám, hogy ha valamilyen módon kellene választ adnom neked, azt mondanám, hogy elsősorban olyan termelési környezetek vannak, ahol azt látjuk, hogy az emberek befektetnek ehhez a termékhez .

Dez Blanchfield: Persze, igen, és érdekes volt hallani, hogy különböző árazási pontokkal rendelkezik, mert nyilvánvalóan eltérő a munkaterhelés, és minél nehezebbek lesznek a munkák, ahol minden valódi munka elvégzésre kerül. De nagyon sok olyan szervezetet látok, különösen a kormányzatban, és természetesen a védelem területén is, ahol a fejlesztés most ugyanolyan szintű beruházást ér el az eszközökbe és rendszerekbe, mint a termelési környezet, mert sokkal több előzetes tesztet végeznek. Védelemként például vannak olyan csapatok, akik több milliárd tesztet, több száz milliárd tesztet futtatnak az alkalmazásokkal és rendszerekkel és eszközökkel, és megfigyelik azokat, mielőtt még az integrációs tesztelésbe bemennének, mert meg akarják győződni arról, hogy van-e egy beépített kód és az adatbázis az alatt ül. Százmillió iterációhoz vagy ilyesmihez jut, bár amíg a terepen vagy valakire lövöldözve, nem megy fel "bumm".

Bullett Manale: Persze.

Dez Blanchfield: A régi iskolák adatbázis-világában tapasztalatom szerint az adatbázis-környezet olyan dolgát, amely csak az adatokban maradt, és néhányan közületek tudják, nagyon ritkán látják, és nagyon ritkán beszélnek róla, tehát amikor az eszköz és alkalmazásokat fejlesztünk, különös tekintettel az analitikai platformokra, most már a telefonjainkban és az eszközökben is vannak. Látja, hogy az ügyfelek az adatbázis-teljesítmény és az adatbáziskezelés beszélgetését inkább egy napi beszélgetésbe hozzák, szemben a pusztán technikákkal? És tudom, hogy már korábban megemlítette, hogy főleg a DBA-kkal beszélget, de van-e tendencia, amikor ez az általános szókincsben van? Lát-e olyan embereket, akik ezeket a témákat tárgyalják, szemben a geekkel?

Bullett Manale: Nos, ezt nehéz megmondani. Úgy értem, ahogy a legtöbb esetben mondtam, az emberekkel, akikkel az értékesítési folyamat szempontjából mindenképpen foglalkozunk, a gyakorló szakemberek vannak, akik a DBA-k. Tehát a kérdésednél azt mondod, hogy "Általában véve az informatikai szervezet tagjai egyre jobban tudják az adatbázist?" Azt hiszem, ez a kérdés, és azt mondanám, hogy valószínűleg a válasz "igen". Napi alapon valószínűleg nem látom annyira, hogy hol vagyok, de azt hiszem, ha megértem a kérdését, azt hiszem, ez lenne a válaszom.

Dez Blanchfield: Igen, ez rendben van. Valószínűleg ez egy megterhelt kérdés, sajnálom, mert nyilvánvalóan a világodban az ön domináns érdeke a dolgok műszaki oldala. Kíváncsi vagyok abban, hogy a mindennapi tevékenységeim során látom, hogy a szervezetek nagyon korán elkezdenek bevonni ezt a beszélgetésbe. Tehát, amikor új kezdeményezésekről, új projektekről, új munkaprogramokról beszélnek, az egyik dolog, amely azonnal jön, a következő: "Hogyan követjük nyomon, hogyan követjük nyomon, hogyan kezeljük a felmerülő kérdéseket, ahelyett, hogy elindítanák, élő lenne? "

Bullett Manale: Azt mondanám, hogy -

Dez Blanchfield: Sajnálom, folytasd.

Bullett Manale: Azt akartam mondani, hogy látom egy olyan tendenciát, amire gondolnom kellene, hogy mondjak - tudod, a múltban sokszor megkapta: "Problémánk volt, tehát most szükségünk van egy eszközre. " És azt hiszem, hogy egy kicsit több elfogadást látunk annak körül, hogy az eszköz a helyén van, még mielőtt a probléma megtörténne, ha ennek van értelme. Tehát azt mondanám, hogy ez egyértelműen normálissá válik, tudod: “Hé, szükségünk van egy ellenőrző eszközre, szükségünk van valamire is.” És az emberek határozottan látják ennek a terméknek az értékét, mert ahogy korábban mondtad, csak hozzá kell adnod a DBA-kat és új példányok hozzáadásával szükség van valamire, amely ezt kezeli. Szüksége van valamire, amely segít ennek kezelésében, és ezért is nagyon sokat fogadunk el ennek a terméknek a környékén, vagy van.

Dez Blanchfield: Gyors kérdés. Hol kell élni? Vajon a LAN hátsó részén kell ülnie, az adatközponton belül, a lehető legközelebb az adatbázis-környezethez, vagy kényelmesen el lehet helyezni valahol, potenciálisan a felhőbe, egy harmadik fél felhőjébe valamilyen akár VPN alagút, akár távoli hozzáférés különböző környezetekhez? Hol kell ülnie ennek a környezetnek és a megfigyelésnek a szempontjából?

Bullett Manale: Az architektúra szempontjából van egy háttér-tárház, és ez egy SQL Server adatbázis. Megvan a konzol, amely lehet kövér vagy vékony ügyfél; lehetőséget adunk mindkettőnkre. És van egy vékony kliensünk, amely valóban kifejezetten a mobil eszközökhöz is igaz. De attól függően, hogy hol lehet ez valójában ülni; ülhet egy környezetben, valójában a legnehezebb rész az, hogy sok információból összegyűjtenünk, bizonyos esetekben, vagy sok esetben adminisztratív jogokat igényel. Most nem erőltetjük téged; Ha szeretné, adatokat gyűjthet, és csak azokról a dolgokról, amelyeket nem tudunk gyűjteni, mivel nincs adminisztrátori jogaink, akkor hagyjuk, hogy ne lássa ezt az információt, ha ezt választja.

Az íztől függően, például ha az AWS-ről beszélünk, egyes környezetekről, jobban működik, mint másokban, de a tényleges környezethez viszonyítva mindenképpen szükség van SA-hitelesítésre az adatok gyűjtéséhez a példányok ellen. Vagy ha ez egy megbízhatatlan domain, akkor általában erre van szükség, de több domain; mindaddig, amíg bizalom fennáll közöttük, összegyűjthetjük őket. Nem igazán számít, ha LAN-on van, vagy WAN-on, maga a tényleges gyűjtés elhanyagolható az összegyűjtött adatmennyiség szempontjából. Ha elegendő méretű WAN-kapcsolatunk van, ez nem jelent problémát. Láttam olyan környezeteket, ahol fióktelepeik vannak, ahol az SQL szervereik vannak az Egyesült Államokban. És ez egy kiszolgáló ezeken a különböző helyeken, és központilag figyelik. A trükkös rész csak annak biztosítása, hogy megfelelő összeköttetéssel rendelkezzen ehhez. Remélhetőleg ez megválaszolja a kérdését, az egész térképén ilyen volt.

Dez Blanchfield: Teljesen. Köszönöm. Két gyors kérdés, amelyek ma reggel érkeztek a résztvevők számára; az egyik: mi a hatása - gyakran látjuk, hogy a rendszermegfigyelő eszközök maguk generálják a terhelést azáltal, hogy csak a dolgokat figyelik, tehát a kérdés az volt, hogy sajnálom, hogy most már letekertem a képernyőmről, de csak átfogalmaztam; megfigyelés útján termelik magunkat? Mérhető-e az eszköz hatása, csak a környezetet figyelve, vagy elhanyagolható hatás?

Bullett Manale: Mindig lesz egy kis hatás, mert lekérdeznie kell az SQL Server példányt az adatok visszahúzása érdekében. Az a kérdés, amit mondtál, "elhanyagolható, vagy jelentős?" A dobozból, amelyet egy példányra mutat, ez elhanyagolható. Már amúgy is ezt tesszük, amint mondtam. Több mint 20 000 ügyfelünk van, és biztosíthatom önöket, hogy ha ez jelentősen befolyásolja a teljesítményt, akkor nem vállalkozunk. Mindezek mellett azt is lehetővé tesszük a felhasználó számára, hogy eldöntse, mit szeretne figyelni. Tehát azt hiszem, hogy fontos megemlíteni, hogy minden környezet kicsit más.

Példa erre a lekérdezés-figyelő komponens esetében az egyik dolog, amelyet meg tudunk csinálni, az, hogy beállíthatjuk-e azt a küszöböt, amelyet Ön a normális határnak tart. Tehát a lekérdezés végrehajtásának idején alapulhat. Ez alapulhat a CPU-n, I / O-n, de példaként mondjuk azt, hogy a végrehajtás idejét null milliszekundumra állítottam be. Valójában azt mondom az eszköznek, hogy összegyűjti az összes lekérdezést, amely az utolsó húzási intervallum óta futott, és a történeti gyűjteményemnek ezt a részét is készíti.

Most, amikor ezt megtesszük, bármilyen mennyiségű lekérdezést összegyűjtünk, amelyeket a legutóbbi szavazás óta a dobozon futottunk. Most ez választható, és a felhasználónak lehetősége van erre. Azt mondjuk, hogy "Ezt kell tennie"? Nem. De mi azt is megadjuk Önnek a választási lehetőségét, hogy ezt megtegye, ha olyan adatmintát szeretne, amely lehetővé teszi az információ gyűjtését. Tehát általánosságban véve megvan az eszköze a eszköz, amellyel beállíthatja és pontosan beállíthatja a kívánt módon, az Ön kényelme alapján. De megvan az a képessége, hogy valóban kinyitja, ha szeretné, és rengeteg további információt gyűjthet, amelyeket nem feltétlenül rendszeresen rendszeresen gyűjtsük össze, ha ennek van értelme.

Dez Blanchfield: Igen, teljesen. Tudom, hogy egy kicsit tovább futunk, de két igazán nagy kérdés van, amit fel akarok vetni, mielőtt bepakolnám. Mindkettő közvetlenül hozzám érkezik, de szerintem a legjobb, ha válaszolsz rájuk. A kérdés általában az volt, hogy "Mi az eszköz elérhetõsége a létezõ rendszerek ismeretében?" Tehát csatlakoztassuk ezt az eszközt, és automatikusan felismerhetjük-e az ott lévõ platformot, és tudjuk, hogy mi az a rendszerre normál, és azonnal vedd fel, amint Mark korábban beszélt? A platformok alapvető ismereteinek némelyike ​​azáltal, hogy, tudod, nem tudom, lehet, hogy a Microsoft Dynamics. Mi a platform ismerete a normál és az üzlet környékén használt jelenlegi, elérhető polcokon belül?

Bullett Manale: Azt mondanám, hogy általánosságban elmondhatjuk, hogy amikor az SQL példányról adatokat gyűjtünk, a bevált gyakorlatokkal kezdjük dolgozni, kezdve a küszöbértékekkel és azok elérési helyével kapcsolatban . Ennek ellenére azt is felismerjük, hogy bárkivel is beszélsz, a bevált gyakorlatok szempontjából, minden környezet más. Amit kezdetben megteszünk, csak az adatokat gyűjtjük, és amit javasolunk az embereknek, 14 napig próbálhatja ki a terméket, ha erre van szüksége. Körülbelül két nap múlva pedig látni fogja, hogy a kiindulási adatok feltöltődnek. Ha elegendő mintaadattal rendelkezik ahhoz, hogy dolgozzon, akkor megkezdi a kontextus megadását az alapvonalhoz, ahol a tartomány van, és az összes ilyen dolgot. Ezután onnan, ha szeretné, automatikusan beállíthatja a küszöböt az összegyűjtött információk alapján. Kicsit el kell kezdeni a kezdeti gyűjtést és a lekérdezést, hogy elkezdhessük meghatározni, mi a normális, és így elkezdhetjük a küszöbök eltolását.

De azt gondolom, hogy érdemes megjegyezni azt is, hogy ha megváltoztatja ezeket a küszöbértékeket, akkor ez megtörténhet csoportjainak csoportjai alapján. Lehet, hogy egy példányra vonatkozik, vagy megteheti az összes példányával szemben, valamint képes létrehozni olyan dolgokat, mint sablonok, hogy mondhassa: "Ez egy termelési példány, de ezt a sablont szeretném hozzárendelni. " És tehát amikor egy új termelési példány online megjelenik, automatikusan alkalmazzuk ezeket a küszöbértékeket, mert ugyanolyan típusú hardverrel rendelkezik, és általában azonos munkaterheléssel rendelkezik, így képesek lennénk erre is. Remélhetőleg ez segít a kérdésben.

Dez Blanchfield: Teljesen. Valójában egy másik kérdésre válaszoltál, amely éppen feljött hozzám, és a következő volt: "Van-e próba letöltés?" Van, erre tudok válaszolni, tudom. Biztos vagyok benne, hogy megerősíti, hogy ingyenesen letölthető, és szerintem azt mondta, hogy 14 nappal később jelenik meg a weboldalon. Letöltheti és játszhat vele. Nagyon gyorsan azt hiszem, hogy "Milyen környezetre van szükség ahhoz, hogy futtassam a próbaverziót? Futtathatom-e azt a laptopomon és játszani vele, vagy tényleg szükségem van egy szerverre?"

Bullett Manale: A legfontosabb, amire szüksége van egy tárolónak, egy SQL Server adatbázisnak, amely legalább 2005-ös. Ezen kívül van néhány minimális erőforrásigény, egy .NET követelmény, és ennyi. Tehát csak a termék telepítésének és az adatbázis létrehozásának a kérdése.

Dez Blanchfield: Tökéletes. Az utolsó kérdés, amit rád dobok, mert most már nem jártunk ide, de gyorsan, körülbelül két vagy három ember feltette a kérdést: "DBA-nak kell lennem, hogy valóban fel tudjak állni és futni vele ezt, és játssz vele?

Bullett Manale: Nem. Azt mondanám, hogy ha DBA vagy, akkor az eszköz különböző felhasználási lehetőségeit fogja használni. Úgy értem, valószínűleg egy kicsit több érték lesz, ha tapasztalt DBA-k vagytok. Sokkal mélyebben látni fogja azt az eszközt, amelyet ki tudna használni. De új DBA-ként vagy akár olyan személyként is, akinek ez nem DBA, és nagyon sok ajánlásunk van, és most ezen az oldalon vagyok. Ezek az ajánlások rendszeresen kerülnek előterjesztésre, és az igazán jó dolog az ajánlásokkal kapcsolatban, hogy megadják az indokokat, miért teszik az ajánlásokat. De ezen túlmenően linkekkel is rendelkeznek a külső tartalmakhoz, amelyek részletesebben leírják az ezen ajánlások megfogalmazásának okait. Tehát ez hivatkozik a külső Microsoft webhelyekre, blogokra és mindenféle ilyesmire, ez külső.

De hogy válaszoljon a kérdésére, ez olyan, tudod, ha idősebb DBA vagy, akkor itt lesz dolgok, valószínűleg ki fogják használni az előnyeit, amelyeket valószínűleg nem kezdő DBA-ként szeretne. De ugyanakkor ez is egyfajta tanulási eszköz, mert mivel áttekinti ezeket az ajánlásokat, akkor az ajánlások felhasználásával önmagában elkezdi kiválasztani ezeket a dolgokat.

Dez Blanchfield: Fantasztikus. Köszönöm. Nagyon élveztem a demo részt. A bemutató nagyszerű volt. A bemutató fantasztikus volt. A memóriából gyorsan megtalálható egy teljes erőforrás-központ az Ön webhelyén, amelyet azt ajánlom, hogy az emberek nézzenek is meg. Emlékszem, megyek át tegnap este, hogy apró részleteket kapjak. Számos dolgod van, csak a blogjaitól, az adataitól és a beszélgetéseitől egészen a memóriáig, és a legtöbb termékdokumentációját online is megtalálja, igaz?

Bullett Manale: Igen, ez helyes, és azt hiszem, hogy Ön a közösségi.idera.com webhelyre hivatkozik. És akkor egy dolgot megemlítenék, amelyet korábban már feltettél: "Meg fogja ismerni a környezetet?" Az új példányok vagy a példányok hozzáadása szempontjából létezik egy másik eszköz is, amely felfedezi a példányokat. És az egész a készletről és a készlet kezeléséről szól. Szeretnék erre az irányra mutatni, a példák tényleges felfedezése szempontjából. De ami a tényleges teljesítményt és megfigyelést illeti, mindazokért a dolgokért, amiről beszéltünk, itt a Diagnostic Manager fog játszani.

Dez Blanchfield: Fantasztikus. Nézd, nagy lefedettség. Nagyon élveztem az előadást. Szerette az élő demonstrációt, és ennyi tőlem van ma reggel, mivel tudom, hogy valószínűleg 10 perc alatt elmentünk az idő múlásával. Eric, visszaadom neked.

Eric Kavanagh: Jól van. Én csak imádtam a demót. Örülök, hogy elkészítette a bemutatót. Örülök, hogy ezt egy nagyon kemény pillantást vettek erre a kérdésre és válaszra.

Bullett Manale: Nagyszerű.

Eric Kavanagh: Mivel ez ad egy képet az emberekről arról, hogy mit néz, és ez tényleg nagyon meghökkent, hogy azt gondoljam, hogy még mindig megtanuljuk, hogyan kell beszélni ezekkel a számítógépekkel, amikor odavisszük. Úgy értem, a diagnosztika ilyen szintje elég kifinomult, és minden nap javul. Sokkal több betekintést nyerünk ahhoz, hogy mi történik valójában. De valóban szüksége van egy emberre, aki figyelmen kívül hagyja ezeket a dolgokat, elolvassa és elviszi ezt a kognitív képességet mögött, amit csinál, igaz?

Bullett Manale: Igen, sok esetben értem - bárcsak azt mondanám, hogy ez egy DBA a dobozban, de éppen túl sok dolog folyik itt. Úgy értem, iránymutatást nyújtunk és segítséget nyújtunk, de a nap végén az embereknek döntést kell hozniuk az általunk bemutatott adatokkal kapcsolatban. Nem hiszem, hogy ez hamarosan megváltozik.

Eric Kavanagh: Nos, ez jó hír a valódi emberek számára, emberek.

Bullett Manale: Így van.

Eric Kavanagh: Azt akarja, hogy valaki figyelje ezt, egy csapat figyelje ezt, és megtanulja, amint a Bullettől hallotta, hogy megnézi ezeket az ajánlásokat, és felveszi, mi folyik itt. És azt hiszem, a történelem alapján, és azt hiszem, megérintette ezt, Bullett, de nagyon gyorsan, hogy a történelem lehetővé teszi, hogy felismerje a jelentős mintákat, és így képes legyen azokat azonosítani, amikor a jövőben bekövetkeznek, nem igaz?

Bullett Manale: Ez helyes. Az egyik dolog, amit megtehetünk, a lekérdezés teljesítményének időbeni nyomon követése. Nyilvánvalóan nézhetünk más dolgokat is, például az alapvonalakat, és láthatjuk, hogy azok eltolódnak, és nyilvánvalóan riasztásokat és hasonló dolgokat kaptunk, amikor ez megtörténik, így határozottan megvan ez a képesség.

Eric Kavanagh: Jól hangzik, emberek. Nem lennénk itt sokáig, de szerettem volna felkeresni ezeket a kérdéseket. Nagyon köszönöm az idejét és figyelmét. Mindezeket az internetes adásokat archiváljuk. Ugorjon online a Techopedia.com-ra vagy az InsideAnalysis.com-ra, mindkét oldal linkjeit látja.

És ezzel búcsút mondunk Önnek. Ismét köszönöm, emberek, a jövő héten még három web-közvetítéssel, kedden, szerdán, csütörtökön találkozunk. Tehát a jövő héten beszélünk veled, emberek. Vigyázz magadra. Viszlát.

Techopedia tartalompartner

A Techopedia munkatársai kapcsolatban állnak a Bloor Csoporttal és kapcsolatba léphetnek a jobb oldali lehetőségekkel. Kattintson ide az ipari partnerekkel való együttműködésről.

• Profil
• Weboldal