Itthon adatbázisok A dba álma: a környezet felfedezése és kezelése

A dba álma: a környezet felfedezése és kezelése

Anonim

A Techopedia munkatársai, 2017. február 22

Elvihető: Eric Kavanagh házigazda megbeszélte az adatbázis-kezelést Dr. Robin Bloorral, Dez Blanchfield-rel és az IDERA Binh Chau-val.

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

Eric Kavanagh: Oké, hölgyeim és uraim. Üdvözlet és üdvözlöm még egyszer. Szerda van, négy óra van a keleti idő szerint, és az elmúlt években ez azt jelenti, hogy itt a ideje a Hot Technologies számára. Így van, ez a műsor a Techopedia-val - Techopedia.com. Nézze meg őket online. Szörnyek forgalmát kapják, havonta 1, 5 millió egyedi látogatót. Ez sok a webes forgalom. A mai téma: „A DBA álma: felfedezés és menedzsment az egész környezetben.” Igen, valóban nagy kérdés, főleg a nagyobb szervezetek számára. Van egy dia arról, hogy valóban a tiéd, és elég rólam, találok fel a Twitteren @eric_kavanagh, mindig megpróbálom követni, és ott folytatni a beszélgetést.

Újra, az adatbázis-technológiákról beszélünk ma, és valóban képesek vagyunk megérteni, mi folyik az adatbázis-példányok széles körében. Mint sokan tudják, miután elkezdte fejleszteni szervezetét, még sok más ilyen példányt kimehet, és ezen dolgok kezelése egy kicsit érdekes kihívás lehet. Valójában emlékszem néhány évvel ezelőtt, hogy nagyszerű beszélgetést folytattam egy srácmal, aki a Védelmi Minisztérium CIO irodájának adatkezelési igazgatója volt. És elmondtam neki ezeket az érdekes dolgokat, megbeszéljük ezt a nagyszerű beszélgetést, és elmeséltem neki hátterű történetemet a szövetségi kiadások átláthatóságának lobbizásáról, ő nevetett, és azt mondta: „Ó, hát a házad, ahova el kell küldenem ezt a következőt. ragadozó drone sztrájk. - Azt mondta: - Átláthatóság a szövetségi kiadásokban? Még azt sem tudom, hogy hány Oracle licencem van itt. ”Amikor ezt hallottam, valóban fel tudtam értékelni a kihívás nagyságrendjét, amellyel egyes szervezetek szembesülnek.

Manapság sok érdekes eszköz található - ezekről ma is hallunk -, hogy megértsük, mi repül odakint, de még 20 évvel ezelőtt ez egy igazán komoly kihívás volt. A DOD méretű szervezeteknél el lehet képzelni, hogy ha olyan ügyet kap, amely sok pénzt fog megtakarítani, sok időt fog megtakarítani, és néhány kormányzási problémát megold meg; akkor egyszerre több kihívást old meg, ha ezt a fajta dolgot helyesen teszi. Ma megtudjuk erről.

Megvan a saját Dr. Robin Bloor, a The Bloor Csoport fő elemzője. Van Dez Blanchfield, adat tudósunk, aki alulról hív be, Sydney, Ausztrália. És Binh Chau, az IDERA vezető termékmenedzsere szintén a vonalon van.

A #HOTTECH-t hashtagként csináljuk - nyugodtan csipogj a show során. És jó kérdésekre támaszkodunk rajtad múlik, ezért kérjük, ne légy félénk: bármikor kérdezzen kérdéseket a webcast-konzol Q&A összetevőjével vagy a csevegőablakkal, akárhogyan is. És ezzel átadom Dr. Robin Bloornak. Hadd adjak át neki a WebEx kulcsát. Ott megy, és vegye el.

Dr. Robin Bloor: Oké. Nos, menjünk tovább az első diához. Olaszországban Stanlionak és Olionak, Laurelnek és Hardynek hívják őket. Az 1990-es években, amikor mindenki aggódott a 2000. év miatt, számos 2000-es projektben vettem részt. És elmentem - hívjuk őket egy nagy biztosítótársaságnak -, és rájöttek, hogy több mint 500 alkalmazásuk van, amelyekről nem tudták, hogy létezik a mainframe-en. Leltárt készítettek a nagygépről. Nos, akkoriban a mainframe környezetet sokkal jobban gondozták, mint bármi mást, ami később jött, úgy értem, erről csak nincs kérdés.

Valóban megdöbbent, beszéltem az emberekkel a szervezetben, és azt mondták, hogy nem létezik központi átfogó… alapvetően tudod, hogy nem volt felelős az információ megértéséért. Soha nem készítettek leltárt vagyonukról. És az adatbázis egyértelműen értéket képviselő eszköz, mert adatokat tartalmaz és az adatok értékesek. Hány esetben van a kérdés, és valójában hol vannak? Ez csak „Mi az adatbázis?”, És úgy gondolom, hogy az adatbázis egy szekrény, amelybe az adatokat dobjuk. És nemrég beszéltem egy webhellyel, amelyen több ezer Oracle példány volt. Nos, az Oracle egy adatbázisa, amelyhez bármilyen kifinomult módon igényel DBA-t.

Erről valami kérdezték, és azt mondták, hogy, azt hiszem, ez körülbelül hét vagy nyolc DBA az egész szervezetben. És azt mondtam, hogy tudod: „Ki vigyáz a többi ezer példányra?” És azt mondták: „Nos, mi történt, az az, hogy az emberek csak fájlrendszerként használják. Számos olyan adatbázisunk van, amelyek nagy klasztereken helyezkednek el, ahol a teljesítmény valóban fontos, és vannak olyan DBA-k, amelyek állandóan felettük állnak. És akkor ezer más adatbázisunk van, amelyeket senki sem vigyáz. ”És pontosan megkérdeztem tőlük, hány adatbázis található, és feljöttek:„ Nos, az Oracle legutóbbi ellenőrzése alatt állt. ”Maguk nem végeztek ellenőrzést., tudod, ami ilyen érdekes dolog.

De tudod, vannak okok az adatbázis használatára. Az adatbázis végrehajtja az adatmodellt. Az adatok megosztására szolgál: tudja kezelni több egyidejű adatkérést, végrehajthat egy biztonsági modellt, megfelel az ACID-nek, rugalmas vagy beállítható rugalmassá. Ez az oka annak, hogy adatbázisunk van. De, tudod, nem szokatlan, hogy az SQL Server vagy az Oracle több ezer példányával rendelkező webhelyekkel találkozunk, és ezek többségét alapvetően csak fájlrendszerként használják. És miért hozna létre valójában egy új példányt?

Tudom a fejlesztői csapatokat, hogy ha új alkalmazást építnek, akkor egy silóba építik, így minden adott új alkalmazásnak külön adatbázisa lenne. Nem feltétlenül próbálnák az adatréteget kiépíteni a dolgokból - nem hiszem, hogy ez jó gyakorlat. De ismét, tudod, ha nagyon bonyolult környezeted van, nagyon-nagyon nehéz lesz megpróbálni összeszerelni az összes olyan adatbázist, amelyek kapcsolatban állnak egymással kapcsolatban, ha az adatok vannak benne, ahol kapcsolatok vannak. Az példányok replikákhoz készülnek.

Tudod, rendelkezésre állási célokra forró készenléti vagy replikák is lehetnek, de adattérképeken is vannak replikák vagy félig replikák. És miután bevezették az adattárház-világot, felmerül a kérdés: tudod, hány adatkártya volt odakint, és az emberek csak klónfájlokként használták őket, kihozták az adatokat az adatraktárból, és nem különösebben törődtek az adatok teljesítményével a értelemszerűen csak alapértelmezett teljesítményként fogják csinálni. Ezeknek az embereknek a többsége valószínűleg még azt sem tudta, hogy valóban be tudja hangolni az adatbázisokat. Láttam olyan terveket, amelyek az adatokat megkülönböztető rakásokká osztották el a terjesztés céljából.

Tudod, gyakran fordul elő ez a replikációs helyzet, amikor több depóval rendelkezik egy szervezeten belül, és mindegyikük rendelkezik adatbázisokkal, és mindegyik egy központi adatbázis szitája. Példákat kap a shardingból. Rossz tervezési döntések - láttam, hogy néhány igazán bizarr tervezés történik az adatbázisok tekintetében, ahol az emberek külön ok nélkül hoztak létre külön adatbázisokat. És amint megjegyeztem, az adatbázisok fájlrendszerek.

És akkor ott vannak a tesztelési és fejlesztési környezetek, amelyeket fel kell állni és le kell esni, de mindegyik adatbázis alapú példánynak számít, és egyébként mindegyiknek biztonságot kell nyújtania, és az összes többi anyagnak, amelyet az adatbázis remélhetőleg biztosít. Példánymegfontolások - az adatbázis-terhelés csak egy adott példányra optimalizálható. Ha igazán érdekli, hogy a lehető legjobban teljesíthessen, akkor ha az adatok nagyszámú adatbázisban leszúrva vannak, akkor ez nem feltétlenül jelenti ezt a fajta optimalizálást.

Ennek oka van, hogy ne hozzon létre hamis adatpéldányokat. A vegyes munkaterhelés ugyanolyan adatbázisban, mint az ellenpont, gyenge teljesítményhez vezethet - különösen figyelemreméltó az OLTP és a nagy lekérdezés forgalom egyszerűen nem keverhető össze, soha nem keveredtek össze, és valószínűleg soha nem is keverhetők össze. Általában a legjobb, ha egy adatbázist kiszolgálói szinten konszolidálunk, nem pedig több virtuális géppel. De a virtuális gépek biztosítják az elszigeteltséget; Néhány embernél ez egy tervezési döntés az adatok elkülönítésétől más adatokkal, hogy tudjuk, ha az alkalmazás sikertelen, vagy ha az adatbázis meghiúsul, akkor az nem csökkenti az alkalmazásomat.

A probléma természetesen az, hogy végül elfut a következő pontra, azaz az adatbázis licencdíjaira. Ezek eltérőek, de láttam, hogy az adatbázis-licencdíjak tervezési kritériummá válnak, mert valaki nem akart egy adott számot felrobbantani, és emiatt az emberek a rendszert nem egyszerűen tervezik az adatbázis-licenc működésének miatt. És van egy másik dolog: ha elkezdi összes adatbázis konszolidációját, érdemes megjegyezni, hogy a DBA-k drágák. Ez nem olyan könnyű dolog.

Egyszerű világnézet - és ez valóban az utolsó diák - van egy adatréteg, egy szállítási réteg és egy feldolgozó réteg. És az összes hardver alá tartozik. Valójában nem lehetséges az adatréteg optimalizálása anélkül, hogy pontosan tudnánk, mi és miért van benne.

És ezt mondva, lejjebb továbbadom barátomnak, Dez Blanchfieldnek.

Dez Blanchfield: Köszönöm, Robin. Hadd rendezzem itt az egeret. Tehát ma néhány anekdotát fogok adni nekem, mert ez egy hatalmas téma, és két hetet tölthetek egy táblás jelölővel, hogy jól érezzem magam, mert közel három évtizeden át voltam lefelé és lefelé ezen a téren. .

De először egy mentális vizuális kép. Amikor arra gondolok, a kihívásról, amelyről ma beszélünk - és lényegében az adatbázis-növekedésről, a replikációról és a szóródásról, valamint az ezzel járó minden kihívásról beszélünk, azt akartam, hogy ezt a képet egy óriás tölgyről ész. Ezek híresen gyönyörű fák, apró makkként indulnak, de ezekhez a behemothokhoz nőnek. És amikor ezt megteszik, nagyon nagy és rendetlen. És amint az a képről látható, mint egy vizuális metafora, ha szereted, tudod, az ágak mindenhova megynek, majd ágak jönnek le, és levélnek végükön vannak, és véletlenszerűen kaotikus alakban vannak, és ez csak a föld felett láthatjuk.

Azokra az adatokra gondolok, mint az adatbázis belsejében lévő adatokra, és az alatt egy gyökér struktúra van, és mindenféle irányba belemennek. De nagyon tiszta és ésszerűnek tűnik a talaj felszínén, ahol szép és sima, de a valóság az, hogy ugyanolyan őrült a föld alatt, mint a föld felett; csak nem látjuk. És ezt gyakran használom, amikor arra gondolok, hogyan lehet leírni azt a kihívást, amelyről ma beszéltünk, a szervezeteknek az igazgatótanácstól kezdve a műszakiakig, hogy megpróbáljam őket elképzelni, hogy mi történik a szervezetükben. Mivel annyira könnyű megnézni egy számítógép képernyőjét, hogy megnézze ezeket a gyönyörű sor- és oszlopmezőket, és gondolkodjon: "Rendeztük, ez nem nagy ügy." De ez egyáltalán nem így van. És tehát ezen a ponton általában ezt az egy sort sújtom, mondván, hogy a fejemben az adatbázisok olyanok, mint a makkok, tudod, kicsiknek indulnak és növekednek, de mielőtt megtudnád, van egy hatalmas tölgyfák erdője, és így a látvány.

Tehát két anekdotát csak egy olyan forgatókönyv megosztására, amely kihalt az ellenőrzésből, és amelyet egyszerűen nem tudtak rögzíteni, majd egy másik, amely hasonlót tett, de képes volt rögzíteni, és rámutatok a mai vita legfontosabb pontjára, hogy mi létrejöttünk.

Az első egy olyan forgatókönyv volt, amikor a legnagyobb szándékkal rendelkező CIO akaratlanul akaratlanul kiváltotta az egyik legváratlanabb és nemkívánatos terjeszkedést, amely éppen az ellenőrzésen túllépett. Olyan forgatókönyv volt, amikor egy több ezer alkalmazottat foglalkoztató, nagyon technikailag hozzáértő személyzettel rendelkező kormányzati szervezet megkövetelte a hozzáférését a rendszeréhez és eszközéhez, hogy megkezdhessék együttműködésüket és automatizálhassák sok folyamataikat. Meg akarták menekülni a papírlapoktól, és online rendszereket akartak létrehozni, az adatokat rögzíteni és nyomon követni, megfigyelni és jelentést tették, és visszaadhatták társaiknak.

És vannak mindenféle dolgok, vannak dolgok az emberektől az irodájukig fordulva, biztonsági okokból bejelentkezve és bejelentkezve egészen azig, hogy ki rendelte meg, amit ebédlőben a kávézóban. Így egy jó szándékú CIO úgy döntött, hogy a Lotus Notes nagyszerű ötlet, mivel szemináriumok sorozatán járt, és az IBM nagyszerű munkát végzett a hangosításban, és a helyes forgatókönyv szerint nagyszerű döntés lett volna, ellenőrzés alatt történt. De ami történt, az ahelyett, hogy a Lotus Notes-t egy technikai embercsoportnak adták át, hogy rendezzen egy környezeti megvalósítást, majd ésszerű eszközöket állítson fel és így tovább, és biztosítson némi irányítást és irányítást körülötte, ami valójában történt, ha a szabványba telepítették operációs környezet, SOE, tehát minden asztal eredményesen szerverré vált.

Így oktatást és gyakorlati jegyzeteket, valamint dokumentumokat bocsátottak rendelkezésre az egész folyamathoz, és hirtelen az emberek rájöttek: „Ja, nekem van Lotus Notes az asztalomon!” Mit gondol, mit gondol? Nos, ez azt jelentette, hogy nagyon technikailag hozzáértő alkalmazottak ezreit tanították arról, hogyan kell szkriptezni és írni alkalmazásokat, hatékonyan, a Lotus Notes-ban, kis adatbázisokat létrehozni, amelyek lényegében táblázatok, sorok, oszlopok és mezőknek tűntek, és ezeket a kis webes felületet a Domino-n keresztül mutatják be.

Ha valamiről információt szeretnék gyűjteni, el tudtam készíteni egy kis űrlapot és táblázatkezelő felületen, fájlba tenni, létrehozni egy kicsi Lotus Notes adatbázist mögötte, bemutatni webes alkalmazásként, és elkezdeni az információk gyűjtését. És ez egész jól hangzott, amíg évekig nem működik, és hirtelen rájöttek, hogy valaki felébredt és azt mondta: „Hát, tedd fel, miért jelennek meg a LAN-on 10 000 új adatbázis-alapú alkalmazás, és különösen az elmúlt 12 évben. hónapok? Mi folyik itt? Nos, mi történt, lényegében fegyvert adtál az embereknek, és azt betöltötték, és a biztonság kikapcsolt, és természetesen a lábukba lőtték magukat.

És itt van ez a nagyszerű kép, amelyet általában egy olasz művész gondolataiba raboltam, aki ezt a furcsa dolgot csinálja, amikor teherautó-rakomány szépet és szalmát kap, és egy művészeti stúdió közepére dobja, majd a művészeti stúdió kurátora lesz. hogy véletlenszerűen dobjon be egy tűt a közepébe. Aztán napokat tölt az élő takarmányokon, kamerákon, végighaladva a szalmán, ahogyan tűzve keresi a tűt a szénakazalban. Amíg végül, órák és napok után, megtalálja, fel-le ugrik, és izgatott lesz. És egyébként, olasz művész, mit tehetsz? De ez elég humoros, és ha valaha is online nézte, vagy ha online nézi, akkor nagyon katarikus.

Ez egy rémálom forgatókönyv, amikor egy jó szándékú műszaki személy az üzletembereknek - nagyon műszakilag hozzáértő üzletembereknek - olyan szerszámot adott, amely megkönnyítette az életüket. De régen olyan kérdések merültek fel, hogy ki támogatja őket, ki figyeli és támogatja őket, hol vannak ezek az adatok, milyen struktúrában vannak az adatok, ki irányítja a sémákat, mi van, ha új verziót akarok létrehozni, milyen adatok vannak ezekben a verziókban, De teszt-integrációs utazást tehetek-e ezekre a dolgokra?

Tudod, hogy levonhatod saját következtetéseidet arról, hogyan ment, de nem ment jól, és el tudod képzelni, hogy csak több száz terabyte adatnyi adat van, és nem kell biztonsági másolatot készíteni, hatékonyan ülni számítógépeken vagy laptopokon íróasztalon, néhány A rendszerek még csak nem is elérhetők, mert az emberek nem tudták, mikor 5:30 -kor kikapcsolják a laptopot, és hazavivék, hogy olyan munkát végezzenek, amelyet a LAN-on senki sem tudott elérni. Nem ért véget. Nagyon sok adatot meg kellett tisztítani, manuálisan manipulálni és visszahozni egy ésszerű rendszerbe; annak nagy részét csak letörölték és eltávolították, mert nem engedték, hogy tovább terjedjen.

Aztán a második anekdotám a dolgokról, egészen más utazásról. Képzeljen el egy forgatókönyvet, ahol fejlesztések, tesztek, integrációk, rendszerintegrációk, felhasználói elfogadási tesztek, gyártás, katasztrófa utáni helyreállítás, biztonsági mentések és biztonsági másolatok készítése a 99-ig és azon felül, frissítések, javítások, majd demonstrációs környezetek egytől 99-ig és még több. És hirtelen ott ülsz, és így szólok: „Várj, mi folyik, lógj, ki mit használ?” Tudod, ez egy rémálom, amely várhatóan megtörténik.

De ebben a forgatókönyvben az történt, hogy lehetőségem volt bemenni egy olyan szervezetbe, amely a vagyonkezelési üzleti egységet akartam kivonni a bank alap platformjáról, és külön szervezetként felállítani egy vállalkozáson belül alapvetően egy induló vállalkozáson. A kihívás az volt, hogy a vagyonkezelési üzleti egységet és az embereket, valamint a technológiát és az azt körülvevő adatokat a közszolgáltatásokban hozzák létre, hozzanak létre egy induló vállalkozást saját cégünkben, és faragják le, hogy a saját márkáján működhessen.

Ez a bankszektor globális vezetője, amelyet nem nevezek el. Ki kellett vonnunk magát a vagyonkezelési üzleti egységet és az összes dolgot. Tehát az egészet, az összes alkalmazottat, a fizikai infrastruktúrát, és helyezze át új irodahelyiségbe. Az összes üzleti rendszert, az összes szoftvert, az összes adatot, az összes licencet megnevezted. Nos, el tudod képzelni, hogy ez kissé rémálomnak tűnt, amivel elindulhat.

Ha valamilyen összefüggést teszünk körül, akkor az eredeti banki platformon 78 rendszerről beszélünk, amelyek körülbelül 14 alapterméket támogatnak, amelyek mintegy ezer különféle ajánlatot tartalmazhatnak. Több száz és használt élő adatbázis létezik, és amikor azt mondom, hogy használatban van, helyben kellett helyeznünk őket, tehát péntek délután egy környezetben lennének, hétfőn várhatóan máshol lesznek, és szombaton vasárnap pedig ezt a keresztezést kellett elvégezniük, amikor a tranzakciók az egyik bal oldali rendszerről mentek, mondjuk, hogy megjelenítsük, a jobb oldalon egy másik rendszerre.

Körülbelül 15 000 ügyfél számtalan rekordral és egy ETL rémálommal, mert az egyik oldalon lévő 78 rendszer egyikének sem volt megfelelő a másik oldalon lévő rendszer. Teljesen új banki platformmal, új rendszerekkel, új szoftverekkel, új adatbázisokkal és új sémával rendelkeztünk. Tehát metaadatok, mezők, sorok, oszlopok, rekordok, táblázatok, nevezted el, semmi nem egyezett. 14 különböző aktív fejlesztőcsapat működik, minden termékhez egy. És amikor ezt a környezetet felépítettük, azt tapasztaltuk, hogy a fejlesztési teszt, az integráció, a rendszerintegráció, a felhasználói elfogadás tesztelése, a gyártás, a katasztrófa utáni helyreállítás, a demonstrációs másolatok, a biztonsági másolatok, a frissítések, a javítások elvégzéséhez - még egy ilyen hiányztam is -, például és oktatás, ezeknek a környezeteknek 23 verziója volt minden fejlesztőcsoport számára.

Most ülsz, és hirtelen a vér gyűrődni kezd, a bőr megfagy, és a haja áll - ez soha nem érhet véget. Nos, kiderül, hogy nagyon jól végződött, mert az első dolog, amit még a technológiai telepítés tervezésének megkezdése előtt megtettünk, az volt, hogy megszereztük a megfelelő eszközöket. És szerszámokat használtunk, és nem feltétlenül embereket, hanem embereket vezető eszközöket. Eszközöket használtunk az adatok leképezéséhez, eszközöket arra, hogy feltérképezzük azokat az adatbázisokat, amelyekben éltek, az összes metaadatot, a sémát és egészen sorok, oszlopok, rekordok és mezőkig leképeztük.

Tudtuk, hogy honnan jönünk, majd összekapcsoltuk azt a térképpel, amit éppen bevezettünk, mindaddig, amire a hagyományos üzletplatform kinézett, és volt egy-egy összefüggés. És bármi, ami lezuhant a közepén, létrehoztunk egy adatszobát, ahol átmentünk és manuálisan leképezhetjük őket. De mielőtt bármilyen telepítést és ezeknek a környezeteknek az új világban történő beállítását elvégeztük, meggyőződöttünk arról, hogy minden egyes rekord, minden egyes tábla, minden mező, minden sor, minden oszlop, minden adatbázis és a körüli metaadatok, az összes engedélyt és vezérlőt leképezték, egyről egyre. És egyetlen dolgot sem mozgottunk mindaddig, amíg ez a korreláció meg nem történt.

Tehát az ETL darabja rémálommá vált egy meglehetősen fájdalommentes folyamatig, csupán a követett ellenőrzések és folyamatok érvényesítésével. És ezt rendszeresen, szinte óránként meg tudjuk csinálni. A régi világban a termelésről a fejlesztési, tesztelési, integrációs stb. Környezetre való átállást hajtottuk végre az új világban. És azon a napon, amikor élővé váltunk, egy öt hónapos folyamat után egy hónappal a tesztelés után, majd hat hónapban online és aktív volt, csak egy kérdésünk volt, és az a kérdés, hogy valaki elfelejtette a jelszavát és vissza kellett állítani. Ez volt az egyetlen kérdés, és lényegében körülbelül egy órás stresszt okozott az embereknek, gondolkodva, hogy valami rosszul ment - kiderült, hogy a jelszó lejárt, és elfelejtették, mi az, és vissza kellett állítaniuk.

El tudod képzelni ezt a forgatókönyvet, összehasonlítva a Lotus Notes környezettel, ahol valakinek nagy szándékai voltak, de nem gondolták át a kihívást, és a következő lépésként el kellett próbálnunk feltérképezni ezeket az adatokat, és ezek nagy részét le kellett írni és ez csak idő és erőfeszítés, erőforrás és morál nagy vesztesége volt. Egy olyan forgatókönyvhöz, amikor megfelelően megtervezzük, elvégzzük és megfelelő módon szállítjuk a megfelelő eszközökkel, nagyszerű eredményt értünk el.

És tehát ez a pont vezeti erre az egy vonalra - mielőtt átadom a munkatársunknak, hogy megbeszéljük, mi az IDERA-nak kell megoldania ezt a kihívást -, hogy a mai világban, ahol egyre több rendszert működtetnek adatbázisok, ez nem csak egy apró, hanem számomra ez tény, szükségszerűség, hogy tapasztalataim szerint az intelligens eszközök az egyetlen módja az adatok felfedezésének, az adatkezelésnek a méretarányú és az elmozdulás sebességének kezelésére.

És ha helyesen hajtják végre, a második anekdotának, amelyet remélhetőleg megmutattam, nagyon fájdalommentes és nagyon zökkenőmentes folyamat lehet. Nem csak az új projektekben, hanem a jelenlegi környezetben is körülkerülve, és biztosítva, hogy bármikor és napban nyomon tudja követni, mi történik a szervezetben, milyen adatbázis létezik, milyen adatbázis-verziókat futtat, és ki mit használ.

És e célból átadom az IDERA munkatársunknak, és nagyon várom, hogy meghallgassam, mit kínálhatnak az asztalon, és hogyan tudták megoldani ezt a kihívást.

Binh Chau: Nagyon köszönöm, Dez. Srácok hallhatsz engem rendben? Rendben, köszönöm. Üdvözlet mindenkinek, Binh Chau vagyok az IDERA-val. Ma egy kicsit beszélek azokról a termékekről, amelyeket SQL Inventory Manager-nek hívtunk, és arról szól, hogy felfedezzük és képesek vagyunk az SQL Server példányait és adatbázisait ott tárolni, és hogy megismerkedjünk azzal, ami van a környezetről, és beszélni kell más dolgokról, amelyekről Dez és Robin beszélt az adatbázis-terjeszkedés és az adatok szükségessége szempontjából manapság.

Ezzel itt van néhány megfontolás, amelyet, azt hiszem, anekdotikusan hallottál azon a két mesén keresztül, amelyet Dez leírt. De manapság alapvetően annyira nagy szükség van az odafigyelhető adatokra és üzleti csoportokra, valamint odakint az üzleti csoportokra, hogy felforgassák saját alkalmazásukat és kiszolgálóikat, különösen az SQL Server segítségével, igaz? Mivel könnyen elkészítheti az SQL Express verzióját vagy a BI-szolgáltatásait, sok SUC-szóródás zajlik sok szervezetnél, kicsitől nagyig.

A DBA-k sokszor nem tudják, hogy valaki úgy döntött, hogy elindít egy példányt, ahelyett, hogy egy meglévő példányt hozna létre, létrehoz egy példányt. Nem tudnak ezekről a dolgokról, amíg potenciálisan nem merül fel probléma, és valaki felhívja a DBA-t: „Ó, nem, az alkalmazásom nem működik, nem tud csatlakozni egy adatbázishoz, mi folyik itt?” És tudod, amikor a DBA kérdezi néhány felfedezett kérdés: "Hé, ez nem volt a radarunkon, nem tudtunk róla."

Egy másik az engedélyezési költségek, igaz? Microsoft SQL Server licenc: a működéshez nem kell, hogy rendelkezzen egyedi kulccsal a létező példányszámhoz. Telepítheti, majd ellenőrzést végez. Tudod, később elvégznek egy ellenőrzést, és felfedezik, hogy hány licencet igényel valójában. És tehát, ha ellenőrzést végeznek, és nem ismeri az ismeretlen szervereket, ez drága ellenőrzést eredményezhet. Ezért jó, ha rendelkezik eszközzel vagy leltárral idő előtt, hogy megtudja, mire fizet az engedélyezése, és hogy képes ne csak megismerni, hanem kezelni is.

És akkor, amiről beszéltem, ha sokszor nem ismeri a szervert, ha a dolgok rendben futnak, minden rendben, de csak akkor tudsz tudomásul valamit, amikor probléma merül fel. És ez termelési megszakításokhoz vezethet, vagy esetleg a kiszolgáló nem volt karbantartva, és nem kapott javítást az adott kiszolgálón, és ez problémát okoz.

Néhány kérdés, amelyet egy DBA-nak napról-napra kell tennie, az, hogy szembe kell nézniük, tudod, ezek adminisztratív vagy stratégiai kérdések is lehetnek, ám néhány dolog, például a Microsoft csak kiadta egy kritikus rendszerjavító programot, hány rendszernek lesz szüksége erre az újra tapasz? Ki fogja érinteni a leállás idejét, ha le kell szednem a rendszert, hogy feljavítsam? Hogyan könnyedén hozzáférhetek ehhez az információhoz? Be kell mennem egy táblázatba? Több rendszerbe kell mennem, hogy ezt megtaláljam? Kell-e kapcsolatba lépnem a különböző üzleti csoportokkal, hogy megkapjam ezt a listát? Nagyon nehéz ezt darabolni.

Egy másik jó alapvetően valaki jön, és azt mondják: új adatbázisra van szükségem. X méretre lesz szüksége, és ehhez nagy kapacitással kell rendelkeznie, majd tudni akarják, hová tehetem. Anélkül, hogy tudnánk, mi van a tájban, nehéz megmondani nekik, oké, ide tehetjük itt, itt vagy itt. El kell mennie, és elvégeznie a kézi ellenőrzéseket, amelyekre szükség van ennek végrehajtásához. És beszéltünk az ellenőrzésről és a gazember szerverről.

Ha van egy szélhámos szerver, akkor nem tudja, hogy milyen állapotban van, hát van-e biztonsági másolata, hogy megvan-e minden javítása. Időnként előfordulhat, hogy nem ismeri ezeket a dolgokat, amíg nincs probléma, ami rossz lesz.

Ezek mindenfajta kihívás, kérdés, a DBA napi szinten néz szembe azzal, amit rájuk vetnek. Szóval, meg akartam mutatni neked az SQL Inventory Manager alkalmazást, amely egy olyan termék, amely ott van. Pár dolgot csinál. Felfedezést végez, ami alapvetően olyan, mintha kiment a környezetbe, hogy megnézze, mi az SQL Server ott a környezetben. És akkor automatikusan felfedezhető, tehát alapvetően, ha futtat egy felfedezést, beállíthatja azt, hogy naponta vagy hetente kimenjen oda - bármilyen időkeretet szeretne - új példányok felfedezésére.

Ezután automatikusan regisztrálja ezeket a példányokat, így megkezdheti azok ellenőrzését és ellenőrizheti állapotuk állapotát, majd megkezdheti a példányok katalogizálását és nyilvántartását, hogy jó képet kaphasson az SQL Server tájáról. Mi van ott, mi a termelés, mi a fejlesztés, mi a katasztrófa utáni helyreállítás, mi kevésbé kritikus és tudod, hogy milyen alkalmazások futnak rájuk. Figyelmeztetéseket is kaphat arról, amikor a dolgok ha az állapot-ellenőrzés sikertelen, tehát alapvetően, ha a szerver leáll, vagy számos további dologra, amelyek önmagukkal is megjavíthatók.

Eric Kavanagh: Kicsit puha leszel, csak hogy tudd.

Binh Chau: Sajnálom, jobb ez? Azt akarom csinálni, hogy egy srácot vezetek be egy bemutatón, mutasd meg, hogy mit csinál. Várjon egy percet, hadd ossza meg először a képernyőmet. Srácok, látod a webes felületet? Ez az SQL Inventory Manager felület. A képernyő, amelyet itt mutatok, egy web-alapú felület. A képernyő, amelyet itt mutatok, az Adatbázis-példány nézet. A tetején láthatjuk, hogy más vagyunk. Tehát a „felfedezett” alapvetően az összes olyan eset, amelyet a hálózaton fedeztek fel. És amit meg fog mutatni, az alapvetően.

Eric Kavanagh: Csak egy kicsit kezdsz széttörni ott. Lehet, hogy le akarja helyezni a telefont, és letenni a hangszóróra. Menj tovább.

Binh Chau: Ez a felfedező képernyő mindent megmutat, amit az Inventory Manager felfedezett a hálózatán. Itt fedezték fel, mint ott 1 003 szerver. És elmondja neked a verziót, a kiadást, ha megtalálja, mikor fedezték fel és hogyan fedezték fel. Tegyük fel például, hogy úgy döntöttem, hogy figyelmen kívül hagyom ezek közül néhányat, azaz tudod, talán szeretném figyelmen kívül hagyni a Fejlesztői kiadást, mert ők nem olyan fontosak számomra, mert csak Fejlesztői kiadás; Dönthetek úgy, hogy figyelmen kívül hagyom ezeket, és elhelyezem őket az Ignore fülre, tehát amikor legközelebb futtatom a Discovery-t, nem fogom újra megmutatni nekem. Most kitölthetem az automatikus regisztrációt, vagy manuálisan is regisztrálhatom.

Tehát itt úgy döntöttem, hogy hat példányt figyelek. És itt be van jelentkezve, és rendszeresen ellenőrzi ezeket, majd több ellenőrzést végez, bármi itt van, tudod, minden 30 másodpercenként ellenőrzi, hogy a szerver fel-le van-e, és áttekintést ad mi ez az állapot. Alapvetően itt azt mondja nekem, hogy van egy kiszolgálóm, ami le van állítva, és ez az öt fel van. Azt is megmondja, hogy milyen szerverkiadások, adatbázisok száma, az adatbázisok állapota, esetleges további leltár vagy metaadatok a szerver körül. Innen is megismerhetem az Engedélyezési nézetet. Itt adok nekem néhány olyan Microsoft licencinformációt, amelyre szükségem van, ha előre akarok lépni, ha egy összeget vagy összefoglalót szerezek a Microsoft ellenőrzése előtt.

Itt van a magok száma, a foglalatok száma, a lehetséges alaplicencek, amelyeket a Microsoft 2012-től mutatott be. Ez volt a példánk nézetünk. Áttekintő oldalunk, ez egy olyan oldal, amelyet megnyit. Ez megmutatja a meglévő egészségügyi ellenőrzéseket vagy ajánlásokat, mint most, azt mondja nekem, hogy kilenc adatbázisom van, amelyek nem rendelkeznek aktuális biztonsági mentéssel. Bekattinthatok oda, hogy megnézhessem, hogy mely adatbázisok vannak, és be tudok lépni, ha szükséges. Megmondja nekem az összes legnépszerűbb adatbázist méret szerint, a legnépszerűbb adatbázisokat tevékenység szerint. Bekattinthatok az adott szerverre, és további részleteket kaphatok róla.

Eric Kavanagh: Noha gördülékeny, akkor itt azt mutatja meg, hogy valóban bármit megnézhet, ami a hálózathoz kapcsolódik, igaz?

Binh Chau: Igaz. Ez azt mutatja, hogy bármit választottam az Inventory Manager segítségével. Ez egy SQL Server, itt megmutatja az összes alkalmazást, amely a szerverhez csatlakozik. Ismét be tudok jutni az összes kiszolgálóra társított adatbázisba. Itt tudtam címkézni a dolgokat. Létrehozhatok egy címkét erre a kiszolgálóra, függetlenül attól, hogy pontos pontot tartalmaz-e. Van olyan ügyfeleink, akik ezt használják, például hogy meg akarják címkézni termelési kiszolgálóikat vagy adósságkiszolgálóikat, majd ilyen módon teljes jelentést kaphatnak a dolgokról. Ahogy az Adminisztráció lapra megyek, így tudom futtatni a Discovery-t. A Discovery alapvetően megy ki és fut a hálózatába, és megtalálja az összes SQL Server-et a környezetében.

Itt van ez a Pontos domain, amely a miénk domainje, és beállítottam, hogy azt mondja, tudod, ezen a konkrét tartományon használja ezt a Windows felhasználói fiókot felfedezéshez, és azt szeretném, ha elvégez egy teljes átkutatást. Azt is választhatom, hogy meghatározza-e: „Csak az adott aldomain szkennelése” vagy a „Csak a szülő beolvasása” pontot. De ebben az esetben már mondtam, hogy futtassa a teljes szkennelést. Itt állnak a különböző szkennelési típusok, amelyeket használhatok, és ha elmentem, és alapvetően ez egy feladat, amelyet beállíthatok. Jelenleg nem működik, ami azt jelenti, hogy ezeket a szkenneléseket manuálisan kellett elvégeznem. De ha szerettem volna, napi időben beállíthattam volna, tudod, minden nap futtassam a munkát. Vagy ha úgy döntök, hogy nem futok naponta - ez túl sok - mondhatom, hogy hetente futtassam a munkát egy adott dátumon és időben.

És akkor az automatikus regisztráció itt, ha ez be van kapcsolva, akkor azt tenné, hogy minden alkalommal, amikor új szervert talál, automatikusan regisztrálja azt az Inventory Managerbe, hogy megkezdhessem a figyelését. Ha van valamiféle kiadás, amelyet ki akarok zárni, mint például az, hogy nem érdekel az Express vagy a Fejlesztő kiadás, mert ezek fejlesztési környezet, akkor csak rákattanok az ide, és mit fog csinálni, azt mondja minden amikor új valamit találok, csak hozzáteszem a Készletkezelőhöz, hogy figyelemmel kísérhesse mindaddig, amíg nem fejlesztői vagy Express kiadás van.

És itt állíthatom be a címkéket, így például ha van termelési kiszolgálóm, itt mehetnék és megcímkézhetem azokat. Megcímkéztem az adatbázist vagy a szervert egy meghatározott kék címkével, így például azt mondhatom, hogy ennek az AO_NODE-nek termelési címkével kell rendelkeznie. És ha így kellett volna könnyen eljutnom a szerverre, itt kimenhetek és rákattanhatok a Produkció címkére, és azonnal elviszem a két szerverre. Ez a Explorer nézetünk, és ezt a Tulajdonos, de mondhatnám példánycímke, adatbázisok segítségével is megmutathatnánk, és kibővíthetem, hogy megnézem, mi azok.

Egy másik hasznos szolgáltatás, amelyet építettünk és az emberek itt nagyon szeretik, az a képesség, hogy megnézheti, mit kezeli az Inventory Manager segítségével, és megnézheti, hogy milyen javítási szinttel rendelkezik. Alapvetően itt azt mondja nekem a hat szerver, amelyet az eszközökben kezeltem, függetlenül attól, hogy van-e frissítés a Microsoft számára, és nem, és az a verzió, amelyet vagyok, támogatott vagy nem, és a támogatás állapot. Ha többet szeretnék tudni erről az adott gyorsjavításról, rákattinthatok, és az összekapcsol a Microsoft cikkével, ami a gyorsjavításról szól, és hogy foglalkozom velük. Exportálhatja ezt a listát, ha akarta, így mondhatja: „Hé, talán három ilyen szervert kell javítanom a hétvégén, a másik háromt később.”

Az összeállítási lista - tehát van egy lista, amelyet összehasonlít, hogy megbizonyosodjon arról, hogy verziója naprakész-e. Kimehet és letöltheti ezt a listát, hogy megbizonyosodjon arról, hogy naprakész-e, és rendelkezik-e a legfrissebb listával, amellyel összehasonlíthatja. Egy másik ügyes készletfunkció, amely az embereknek tetszik, az a képesség, hogy nemcsak a címkéket adjuk hozzá, hanem az a képesség, hogy egyéni készlet-mezőket adjunk hozzá. Tudja, ha egy mezőt hozzá szeretne volna adni egy adatbázis címkézéséhez, akkor mondjuk, hogy adatbázis-szintű címkézést szeretnék tenni. Osztály, ez az osztály és ez az adatbázis, más típusú lehet: nyílt végű, igaz / hamis vagy válogatott.

Mondhatnám, tudod, ez HR, marketing, K + F, pénzügy. És ez itt alapvetően az, hogy ha egyszer megcímkézi ezeket a dolgokat, akkor innen kihozhat néhány adatot, amely kimondja, hogy mekkora kapacitást használ az egyes adatbázisok, és elkezdhet valamit, növekszik-e, és van-e értelme visszafizetni ezeket az osztályokat?

Egy másik dolog az, hogy ha karbantartást kell futtatnia, azáltal, hogy megtudja, ki van az adatbázisban, tudja, kivel kell kapcsolatba lépni, hogy tudatja velük: „Hé, karbantartást kell végeznem ezen a hétvégén, az adatbázisai offline állapotban vannak”. és így tovább, és így tovább. Egy másik hasznos szolgáltatás az itt keresett keresőmező, amelyet az emberek szeretnek. Sokszor a DBA-kat kérdezik adatbázisról, alkalmazásról vagy szerverről, attól függően, hogy ki beszél velük, nehéz pontosan kitalálni, hol van. Amit itt tehetsz: nem biztos, hogy tudod, hol él az adatbázis, de beírhatod. Beírhatom az IDERA irányítópultot, és össze fog hozni egy pár adatbázist, és hol ülnek, így könnyen elérhető azoknak. Ezután további információkat gyűjt róluk: méretüket, naplóméretüket, függetlenül attól, hogy volt-e már biztonsági másolatot, milyen helyreállítási módban van, ha bármilyen címkét szeretnék hozzátenni. Ebben az eszközben nagyon sok különböző funkció található, tudod, ez egy leltárkészlet, de egy leltárkészlet, amely nagyon specifikus az SQL Server és a DBA számára.

Mert, azt hiszem, vannak további dolgok, amelyekhez a DBA hozzáférést szeretne kapni, vagy hogy valamilyen módon jó képet kapjon arról, hogy a környezet és táj hogyan néz ki az adatbázisukban. Feliratkozhat, konfigurálhatja az SMTP-kiszolgálót és beállíthatja az előfizetést, hogy figyelmeztessen magadnak vagy az itt található felhasználóknak. Megállítom ezt, és visszatérek a bemutatóhoz. És ez az utolsó dia itt csak egy egyszerű kilátás az építészetre. Ez egy webkonzol, amely beágyazott Tomcat webszolgáltatásokon fut.

Van néhány gyűjtőszolgáltatás és felügyeleti szolgáltatás, amelyeket tárolóba helyezünk, és a felügyeleti szolgáltatások kialszanak, és futtatják a Discovery szolgáltatást az Ön különböző SQL Server példányaiban. A monitor-szerverekre nincs telepítve semmi. Van olyan feladatok, amelyek rendszeresen futnak, és csak adatokat gyűjtenek róla, tehát alapvetően akár felfelé, akár lefelé, mennyi adatot használnak, mi az emberek más verziói. Nos, ennyi.

Eric Kavanagh: Igen, hadd tegyem fel Önnek néhány kérdést, és akkor biztos vagyok benne, hogy Robinnak és Deznek is vannak kérdései - csak a kíváncsiságból, amikor valaki ellenőrzést készít, mondjuk a Microsoft, használják ezt az eszközt, vagy feltételezem, hogy vannak valamilyen szabadalmaztatott eszközük, amelyeket használnak?

Binh Chau: Igen, azt hiszem, szabadalmaztatott eszközöket használnak. A lényeg az, hogy ez az eszköz egy leltár eszköz, tehát naprakészen tartja, tudod, mert feladata kimenni és folyamatosan információkat gyűjteni a szervereiről, ott kifogy, és bármikor, naprakész információkkal rendelkezel, valójában arról, hogy a dolgok hogyan változnak, és tudod, egyszeri jelentésekkel kaphat a Microsoft-tól, amelyek azt mondják, hogy ez a kiszolgálók száma van, ezek a verziók .

Eric Kavanagh: Igen, kíváncsi vagyok a Discovery-re. Tehát amikor valaki megvásárolja ezt az eszközt és elkezdi használni, hogyan történik a felfedezés? Ez volt az a fajta, amire korábban hivatkoztam, vagyis arra, hogy megérinti a hálózatot, hogy megnézi, mely jelek repülnek oda, amelyek adatbázispéldányoknak tűnnek, majd katalogizálja azt, majd miután megcímkézett egy adatbázispéldányt, amely figyeli? Azt hiszem, van egyfajta ping, amit gyakran tesz, és ha például leesik, akkor tudod, hogy lement. Így működnek a dolgok?

Binh Chau: Igen. Úgy értem, ha egyszer bekapcsolta a Discovery-t, akkor kimegy a hálózatába, és számos különféle vizsgálatot végeztünk odakinn, de tudod, hogy ez egy böngésző és a regisztrációs vizsgálat. Különböző vizsgálatokat végez annak ellenőrzése érdekében, hogy melyik számítógép van odakint, majd ellenőrzi: vannak SQL-kiszolgálók vagy BI-szolgáltatások? Aztán visszahozza, behúzza a szerszámba, és megmutatja neked: "Hé, itt vannak minden, amit felfedeztem."

És akkor, ha azt mondaná, hogy "figyelni akarom ennek az eszköznek a használatával", akkor ezt nyomon fogja követni, és pingolni fogja. Feladatai vannak olyan gyakran pingolni, hogy azt mondják: „Oké, nézd meg most ezt a dolgot” - tudod, az adatbázis elérhetősége - ellenőrizze most az adatbázis előzményeit, ellenőrizze az adatbázis oldalát. A feladatok egy sorát futtatja az ellenőrzött adatbázis ellenőrzéséhez.

Eric Kavanagh: Igen, ez jó. És kérdésünk van egy közönség tagjától. Tudom, hogy srácok, olyan eszközökkel rendelkeznek, amelyek különféle adatbázis-technológiákkal működnek, de ezt főleg ma megmutatod, csak az SQL Server számára, vagy más adatbázis-típusokra is vonatkozik?

Binh Chau: Jelenleg ez az eszköz az SQL Server alkalmazást fedi le.

Eric Kavanagh: Oké, ez rendben van. Nos, hadd adjak át Robinnak. Biztos vagyok benne, hogy van néhány kérdése, majd talán vissza Dez-hez. Vörösbegy?

Dr. Robin Bloor: Igen, persze. A Microsoft nemrégiben - valamikor 2006-ban - bejelentette az SQL Server alkalmazását Linuxon, de nem hiszem, hogy még kiadta. Csak azon töprengett, hogy van-e észrevétele? Tudod erről? Te játszol vele?

Binh Chau: Igen, mi vagyunk. Azt tervezzük, hogy ezt belefoglaljuk. Úgy értem, hogy ez az eszköz nagyon jó, sok olyan ügyféllel beszéltem, akik saját háztartási eszközöket építették fel, hogy ugyanazt csinálják, de lépést kell tartaniuk az új kiadásokkal és verziókkal, amelyek A Microsoft megjelenik, de vannak új verziói és kiadásai, korán kezdünk bele, hogy megbizonyosodjunk arról, hogy az eszköz képes-e figyelni és kezelni az új kiadásokat. Tehát az SQL operációs rendszert Linuxon olyan tényezőként tervezzük, amelyet hozzáadunk és elérhetővé teszünk, amikor elérhető lesz - azt hiszem, ez év későbbi szakaszában.

Dr. Robin Bloor: Igen, ez érdekes. Nagyon sok ügyfelétől arra számít, hogy valóban ezt megteszi? A tapasztalatom szerint az SQL Server nagyon kifinomult adatbázis. Úgy értem, tudod, hosszú a foga, valószínűleg ez a mondat. Úgy értem, tudod, az eredeti Sybase, amelyből származik, sok dologban meglehetősen egyszerűsített volt. De a Microsoft egyre több és több dolgot tett az évek során. Mindez elérhető lesz Linuxon? Úgy értem, tanácsot fog adni az ügyfeleknek az áttérés végrehajtásáról?

Binh Chau: Sajnálom, az a kérdés, látjuk-e az embereket?

Dr. Robin Bloor: Nos, mivel összezavarodtál vele, ugyanolyan kifinomult Linuxon, mint Windowson?

Binh Chau: Nem játszottam vele magam, de amit egy kollégámtól hallottam, az az, hogy valójában nagyon egyenlő. De személy szerint nem játszottam az SQL új verziójával Linuxon.

Dr. Robin Bloor: Oké. Jól gondolom, hogy egyszerűen minden ügynököt felhelyezett minden SQL Serverre, amelyet megtalál? Így működik ez az eszköz?

Binh Chau: Nem, valójában nem adunk ügynököket. Ehhez az eszközhöz, a Leltárhoz, ténylegesen nem helyezzünk oda ügynököket. Csak kimenünk, hívunk, és ellenőrizzük az állapotát. Egy szép dolog ebben az eszközben az, hogy ügynök nélküli.

Dr. Robin Bloor: Tehát van más SQL Server eszköze, emlékeztetne arra, hogy milyen más termékekkel rendelkezik ebben a csomagban, amelyek az SQL Serverrel foglalkoznak?

Binh Chau: Igen. Van SQL Diagnostic Manager. Ez egy figyelő és teljesítmény eszköz. Mélyebb elemzéseket vagy diagnosztikai, valamint teljesítmény- és egészségügyi ellenőrzéseket végez az Ön számára, mint az Inventory Manager. A Készletkezelő az állapotfelmérés könnyű változata. Megvan a Compliance Manager és a Secure is, amelyek a biztonsági csomag része. Alapvetően megmondja, ki fér hozzá az adatokhoz, milyen adatokhoz férnek hozzá, miért, és segít a megfelelési és egyéb jelentési irányelvek betartásában. Van SQL Safe, amely a biztonsági mentési eszközünk - biztonsági mentést végez és visszaállít, és ez nagyon jó.

Rendelkezésre áll a vállalati munkamenedzserünk is, amely csak a munkáját figyeli. És akkor megvan az Eszköztár eszköz, amely Admin eszközkészlet, valamint Összehasonlító eszközkészlet és SQL Doctor. Rendszergazda és Összehasonlító eszközkészlet, ezekre gondolok, mint egy svájci hadsereg késre. Több eszközük van, amelyek segítenek a DBA-n különféle dolgok elvégzésében, például tudod, javításokat ellenőrizhetnek, vagy adatbázist áthelyezhetnek vagy klónozhatnak. De az eszközkészletben 24 ilyen eszköz található.

Dr. Robin Bloor: Tehát azok az emberek, akik készletkezelést folytatnak, általában már használják az egyéb eszközöket? Vagy ez egyfajta belépési pont? El tudom képzelni - úgy értem, elmondhatod, ha vannak háborús történeteid -, de el tudom képzelni, hogy ha soha nem vezettek leltárt egy meglehetősen nagy méretű adatközpontban, a tapasztalat meglehetősen nyugtató lehet. Ez az, amit találsz?

Binh Chau: Igen. Úgy értem, vannak olyan vásárlóink, akiket más szerszámkészletek ismerkednek meg az eszközzel, bár vannak olyan ügyfelek, akik ilyen eszközök keresésére jönnek a projektek miatt. Egy példa volt arra, hogy volt egy olyan társaság, amely egyesült egy másik társasággal, és egy sor társaságot vásárolt, és költségeik csökkentése érdekében meg kellett erősíteniük az SQL Server lábnyomukat. És tehát olyan eszközöket kerestek, amelyek segítségével kimenthetnek és felfedezhetnek mindent, ami volt, így elindíthatják a folyamatot, hogyan erősíthetjük meg ezt.

Dr. Robin Bloor: Igaz, értem. Azt hiszem, ez nagyon gyakori az egyesüléseknél, amikor gondolkodunk rajta. Oké, átadom Deznek, nem akarom, hogy minden időben veszem. Nézze meg, milyen kérdéseink vannak Ausztráliától.

Dez Blanchfield: Köszönöm, igen, a kérdések itt mindig fejjel lefelé vannak. Az egyik dolog, ami eszembe jut, és ezt nagyon sokat kapom, tudod, a cégek nem egészen biztosak abban, hogy hol kell meghúzni a vonalat, hogy mikor kezdjék el befektetni. Mikor kellene egy szervezetnek - a tapasztalatai szerint a hideg szakaszban van - mikor kell a megfelelő idő kezdeni befektetni az ilyen eszközökbe, hogy ne kerüljön bajba? Csinálja ezt az első naptól kezdve, amikor megkezdi az új szervezet adatbázis-infrastruktúrájának kiépítését, vagy - amint már rámutattál - amikor felvásárlást / egyesülést hajt végre?

Vagy van egy adott skála, ahol valóban kell lennie? Szüksége van 10, 100 vagy 1000 adatbázisra? Mi az eddigi tapasztalata a piaccal, amellyel olyan régen foglalkozott, mikor van a megfelelő idő bejutni ebbe a térbe, és valószínűleg hol kezdje? Milyen ez az induláskor?

Binh Chau: Úgy értem, talán, ha ez egy nagyon kicsi szervezet, akkor lehet, hogy nincs szüksége erre az eszközre, például egy DBA-val vagy pár DBA-val. Amikor elkezdesz egy, nem tudom, három vagy négy DBA-t és talán 50–100 szervert tartalmazó csoportot kapni, érdemes elkezdened csinálni valami ilyesmit. Azt hiszem, mivel a szervezete nagyobb méretűvé válik, és csak a hozzáértő üzletemberek szeretnének, tudod, hogy az Ön által megadott példához hasonlóan maguk is telepíteni akarják az alkalmazásokat és az adatbázisokat, de éppen akkor szeretnének ez a fajta eszköz, mert így láthatja, mi van odakint.

De még egy kisebb szervezetnél is jó, ha van ilyen típusú eszköz, hogy nyomon tudja követni azt, ami van. Ha feloszlik, hogy azt mondhassák: „Ó, igen, megvásároltam az SQL 2012-et ehhez a dobozhoz, de jelenleg az SQL 2008 fut, mert van egy olyan alkalmazásom, amelyre még mindig szükség van a régi változatra.” Segít abban, hogy csak az Inventory eszköz legyen. hogy elkerülje több olyan tábla kezelését, amelyek elavulttá válhatnak.

Dez Blanchfield: A másik kérdés, amelyet éppen követtem fel: milyen típusú készségeket vagy erőforrásokat kell a szervezeteknek tervezniük, amikor elérik ezt a skálát? Előfordul-e, hogy van egy adott készségkészlet, amelyre igazán szükség van, vagy egyfajta tapasztalat vagy háttér, vagy az a személytípus, amely a legjobban megfelel az ilyen kihívásnak? Vagy valami, amit az átlagos DBA vagy a sys admin vagy a hálózati adminisztrátor típusú készségek meg tudnak dobni? Valóban szüksége van egy éles, hegyes végű agyra, vagy ezt elég gyorsan fel tudja venni?

Binh Chau: Sajnálom, szóval a személy képességeiről beszéltél?

Dez Blanchfield: Igen, tehát amikor egy adatbázis-adminisztrátorra gondol, van egy speciális készség, amelyre szükséged lesz. Tehát, amikor önálló DBA-t bérel fel az adott szerepkörre, amikor elgondolkodik a kihívások típusairól, amelyekről itt beszélt, amikor egy ilyen eszközt használ az adatbázisok feltérképezéséhez és követéséhez, ha felfedezi a darabot, és vezeti ezt a szerszámot, van-e valami egyedi az eszköz használatában és az ilyen típusú kihíváshoz való megközelítésében, vagy valami olyan, amit az átlagos DBA elég gyorsan felvet?

Binh Chau: Úgy értem, azt hiszem, az átlagos DBA gyorsan felveszi ezt. Úgy gondolom, hogy hasznos lenne ilyen típusú eszköz, mert ezt meg is fordíthatja, mert web alapú. A szervezet más felhasználóinak is megadhatja. Adhatná azt az alkalmazásfejlesztőnek, aki ellenőrizheti saját adatbázisát vagy szerverét. Eltávolít néhány adminisztratív dolgot, amelyet a DBA-nak meg kell tennie. Korábban valaki felhívta a DBA-t, és azt mondta: „Ó, miért van fel vagy le a szerver?” Most máris hozzáférhetnek és megnézhetik, hogy szervereik felfelé vagy lefelé vannak-e.

Dez Blanchfield: És milyen környezetre lenne szükség egy átlagos szervezet számára ennek telepítéséhez? Szüksége van egy dedikált fizikai szerverre, vagy meg lehet valósítani egy virtuális gépen? Be tudják állítani a felhő környezetében? Mekkora az eszköz telepítésének általános lábnyoma és csak az eszköz általános működése? Potenciálisan mekkora mennyiségű nehéz vasra van szüksége ahhoz, hogy párhuzamosan futhasson a leképezendő többi környezettel?

Binh Chau: Igen, virtuális gépen, számítógépen vagy szerveren is futtatható. Nem feltétlenül kell dedikált szervernek lennie, csak attól függ, hogy hány szervert figyel. Ha nagyobb környezetben van, akkor segíthet egy nagyobb kiszolgálóban, mivel sok adatot gyűjt az ellenőrzött SQL Serverről.

Dez Blanchfield: Igaz. Ez a fajta dolog, amelyet kényelmesen futtathat a felhőpéldányban, és létrehozhat egy VPN-t a környezetéhez, vagy valószínűleg kissé nehéz az összegyűjtött adat mennyisége az ilyen típusú felhasználáshoz?

Binh Chau: Még nem állítottuk be, hogy a felhőre futtassuk, hogy ezt még a felhőben futtassuk. Valószínűleg a prem-en kell futtatni.

Dez Blanchfield: És az utolsó kérdés, ha tudok: sok eszköz, amelyet ebben a térben láttam, különösen akkor, ha megemlítette egy forgatókönyvhöz, amikor valaki társaságot vásárolt, vagy összefonódás történt, vagy ehhez hasonló valami, vagy akár ha ez egy olyan szervezet, amely csak egyesíti az üzleti egységeket, akkor ésszerű használati eset, ha valaki egy laptopra telepíti és környezetbe veszi, hogy egyszer egy világot ábrázoljon, vagy ez valószínűtlen használati eset? Inkább a helyzet, ha ott lesz, és csak véglegesen hagyja futni?

Binh Chau: Ez az egyedi eszköz inkább egyfajta, amit egy kiszolgálóra telepít, és ott hagyja futtatni. Ily módon összegyűjti a szükséges információkat, és azt hiszem, folyamatos nyilvántartást vezethet arról, ami megvan. Ez ellentétben a Térkép eszközzel, mert a Térkép eszköz olyan, mint egy-egy, ugrás a szükséges porthoz, tegye meg, amit ma kell tennie. Ez egyfajta - a jó érzés az, hogy megcímkézheti azt, hogy az emberek hozzáférjenek ahhoz, hogy ellenőrizhessék az adott szerver állapotát, az őket érdekli.

Dez Blanchfield: Oké. Valószínűleg az utolsó kérdés számomra, majd visszaadom Ericnek a kérdéseket, amelyek a Q&A ablakon keresztül érkeznek a résztvevőkkel, mert ma jó volt a részvételi arány, az egyik kedvencem. Csak ennek befejezése érdekében mire készül a kezed? Tudom, hogy sok eszköze elérhető a vásárlás előtt történő vásárláshoz. Hol kell az emberek többet megtudni erről az internetről, a webhely hollétéről, ha keresik a letöltéseket, és hogyan néz ki az utazás, valamilyen módon megfogalmazni egy koncepció bizonyítékát vagy egy próbaverziót, megkapni a kezét és megismerkedni vele majd vegye fel a kapcsolatot és megvásárolja?

Binh Chau: Igen. Mehet az IDERA.com webhelyre, és ingyenesen letölthet egy kéthetes próbaverziót. És ha tetszik, és kapcsolatba akar lépni velünk, akkor be is tervezhetünk egy bemutatót egy mérnökkel, hogy mélyebben belemerülhessünk a szerszámba.

Dez Blanchfield: Fantasztikus. Nos, köszönöm szépen ezt. Nagyra értékeltem az időt, hogy veled beszélgethessek róla, és személyes tapasztalataim alapján, és biztos vagyok benne, hogy az egész életen át tartó tapasztalataimért Robinért beszélek, azt hiszem, hogy adott, hogy valami ilyen manapság követelmény. Most nem tehetjük meg kézzel, bármennyire is próbálunk; a skála túl nagy, és a dolgok túl gyorsan mozognak.

Nagyon javaslom az embereknek, hogy pontosan ezt tegyék meg, ugorjanak át az IDERA weboldalra, és kapjanak egy másolatot, amellyel játszani lehet. Mivel az anekdotákkal kapcsolatos tapasztalataim potenciális kockázata, amellyel éppen ma osztottam meg, az az lehet, hogy ha nagyon megfelelő eszközökkel rendelkezik, akkor nagyon rosszról nagyon jóra mehet át, de a másik irányba is menhet, ha nem t. Eric, hát hozzád.

Eric Kavanagh: Igen, csak utoljára kérdezzen egy utolsó kérdést, érdekes. Nagyon kíváncsi vagyok arra, hogy mit látsz odakint, tudod, a felhő nyilvánvalóan manapság egyre fontosabb - Amazon Web Services, ám ezek nem az egyetlen, a Microsoft teljes Azure-kínálata úgy tűnik, hogy gőzöződik. Kíváncsi vagyok, hogy az egyik résztvevő azt írja, hogy Dr. Bloor érdekes megjegyzést fűzött ahhoz, hogy a DBA-k drágák, és hogy egy gazember DBA vagy valaki más által okozott kezelési probléma, amely nem azt teszi, amit tennie kellene, megoldható a felhőbe vonulva. Nagyon kíváncsi vagyok, mennyi tevékenységet lát? Látja, hogy a felhőbe történő migráció egyre nagyobb problémát jelent a vállalkozások számára, vagy mi a tendencia?

Binh Chau: Úgy érzem, ez csak attól függ, hogy milyen kérdésben vagy. Az egyes iparágak szerint azt mondják: „Nem, nem migrálunk.” Lehet, hogy nem vándorolnak nyilvános felhőbe; lehet, hogy vándorolnak vagy áttelepítik cuccaikat egy privát felhőbe. De akkor látom néhány olyan szervezetet, amely érdekli, tudod, hogy valóban gyors lépésben lép fel, és egyfajta Amazon vagy Microsoft Azure felé halad. És akkor vannak olyan emberek, akik azt mondják: „Nem, nem migráljuk az adatainkat” vagy „Csak vannak bizonyos adatok, amelyeket áttelepítünk, de nem a kritikus adatainkat.” Azt hiszem, van ilyen három tábor.

Eric Kavanagh: Igen, ennek lenne értelme. Úgy értem, ezt egyre inkább látjuk, és azt hiszem, hogy illik és mozog, és jó ideje indul. És van egy visszahúzódás a felhőhöz is. Az emberek felállnak az Amazon Web Services szolgáltatásaiba - ezt már többször is hallottuk -, és először a költségek kezelhetők, majd az idő múlásával csak kúszik fel, és akkor máris megragadták őket. Sok szempontból a felhő csak egy újabb adatközpont, ám enyhén szólva, ez érdekes utazás lesz.

Nos, az emberek archiválják ezeket a webes adásokat. Ugorjon online a techopedia.com webhelyre, hogy megnézze a dolgok teljes listáját. És természetesen a insideanalysis.com legfrissebb változatát. És ezzel búcsút fogunk adni neked. És még egyszer köszönöm az időt és a figyelmet. Köszönjük az IDERA összes barátjának, és holnap remélhetőleg beszélgetünk veled az adatfilozófiánkkal, amely web-adás csúcspontjává vált. Így van, az adatfilozófia holnap négy órakor keletre van. Remélem ott találkozunk. Vigyázzon emberekre, viszlát.

A dba álma: a környezet felfedezése és kezelése