A Techopedia munkatársai, 2016. május 26
Elvihető: Eric Kavanagh a házigazda az adatbáziskezelésről és a példányok felfedezéséről beszélget Robin Bloor, Dez Blanchfield és Bullett Manale segítségével a Hot Technologies legújabb epizódjában.
Jelenleg nincs bejelentkezve. Kérjük, jelentkezzen be vagy jelentkezzen be a videó megtekintéséhez.
Eric Kavanagh: Jól van, hölgyeim és uraim. Üdvözöljük még egyszer. A nevem Eric Kavanagh. A dolgok forróak. Itt melegsznek a dolgok. Nem tudom, mi folyik itt. Ó, igaz, itt az ideje a Hot Technologies-nek. Igen, a nevem ismét Eric Kavanagh. A Twitteren @eric_kavanagh találhatsz. Ezt a show-ot arra tervezték, hogy bemutassák, mi forró a piacon. A mai cím: „Kulcsok a Királysághoz: Az SQL Server kezelése dinamikus felfedezéssel.” Jó dolog. Igazán van a tiéd. Oké, ez a kép néhány évvel ezelőtt készült. Nem fogok hazudni, egy kicsit idősebbnek nézek ki, de ez rendben van.
Tehát arról beszélünk, hogy a technológiák és az SQL Server valóban, nagyon, nagyon, nagyon meleg. Van egy csomó tartalom ma, tehát azonnal el fogom adni. Készülj fel, itt megyünk. Itt vannak a hangszóróink. És Robin Bloor megy az első helyre.
Robin Bloor: Igen, valóban. A bemutató mélyebben megy az adatbázis-kezelésbe, ezért csak azt hittem, hogy átfutok az adatbázis-kezelésen vagy, tudod, az adatbázis-labirintuson, hogy az embereket beillesztsem a szellembe. Régebben DBA voltam, feltételezem, hogy mondhatnám, hogy adatbázis-tanácsadó voltam kb. 20 évvel ezelőtt, és az a tény, ami tényleg meglep engem az adatbázisokkal kapcsolatban, az, hogy nem sokat változott. Sok minden megváltozott a sebesség szempontjából, az adatmennyiség és az ilyen dolgok szempontjából, de ezek nagy része valójában nagyon hasonló ahhoz, ami korábban történt.
Az adatbázis véleményem szerint egy szervezett, kiterjeszthető adatgyűjtés, amely optimalizálható az adott munkaterheléshez és adatkezelési képességeket biztosít. Elsősorban azért jött létre, mert ha fájlokban kívánta kezelni az adatokat, akkor ez egy nagyon nehéz feladat. És az a gondolat, hogy elkészítünk egy olyan szoftvert, amely nagyjából bármit megtesz, amire szükséged volt, szinte azonnal elindult, mihelyt az 1970-es években véletlenszerű hozzáférést kaptunk az IBM nagyszámítógépein.
A relációs adatbázist a '70 -es években találták ki, és a 80-as évek prototípusainál jött létre, és a piacon a 90-es évek elejétől kezdve vonult piacra. És a relációs adatbázisok továbbra is rendkívül dominálnak népszerűségükben. A sajtó elolvasásakor szörnyen sok mindent hallanak ezekről - az SQL adatbázisokról, és a közelmúltban borzasztóan sok zaj van a gráf adatbázisokkal kapcsolatban. És ezek érdekesek, ha úgy tetszik, de valójában még mindig a legfrissebb eladási számok szerint a relációs adatbázisok piaci részesedése 95%. És a Microsoft SQL Server, amelyet ma mélyebben megvitatunk, a második legnépszerűbb az Oracle számára.
A relációs adatbázisok miatt, amelyek szokatlanná teszik őket a meglévő motorok szempontjából, az képesek mind az OLTP, mind a lekérdezés munkaterhelésein dolgozni. Másképpen kell hangolnia őket, ha ezt megteszi, de valójában mindkét típusú munkaterhelésre képesek. Az egyik rövid véletlenszerű tranzakciók, a másik pedig sok adatot felölelő hosszú lekérdezések. Alternatív megoldásként a NoSQL adatbázis és a gráf adatbázis elsősorban az elemzésre szolgál, és a közelmúltban emelkedtek fel. A NoSQL volt az első, és a grafikon az utóbbi időben kezdett kissé vonulni. A NoSQL használható tranzakciós tevékenységekhez, de a grafikonokat szinte soha nem használják tranzakciós tevékenységekhez. Ennek okán találkoztam olyan statussal, amely valójában azt gondolom, hogy legalább tíz éves, és azt mondja, hogy a legtöbb társaságnak legalább három van, valójában ez az érték 3, 5, különböző márkájú adatbázisok, ha megnézzük a szoftverleltárt.
A valóság azonban az, hogy a legtöbb vállalat szabványosítja egy adott adatbázist. És a legtöbb vállalat szabványosította az SQL Server és az Oracle szoftvereket, mint a két legnépszerűbb szabványos adatbázisokhoz. És csak rendkívüli körülmények között használják az alternatívákat, amikor például olyan szoftvercsomagot kapnak, amelyhez más adatbázisra van szükség, vagy pedig néhány, a létező nagy adatanalitikai célt követnek.
Ha tetszik, beavatkozunk a Hadoopba is. A Hadoop úgy vagy úgy, mint fájlrendszer, de még nem adatbázis. Ennek ellenére van SQL, amely a tetején fekszik. De a bizonyítékok arra utalnak, hogy valójában nem helyettesíti vagy bárhol közel áll ahhoz a relációs adatbázishoz, amely a világ szívét és elméjét megszerezte. És ennek oka valójában az, hogy a relációs adatbázisoknak húsz évre, valójában húsz évnél hosszabb időre volt szükség, hogy olyan jók legyenek, mint amilyenek vannak. És nem csak egy olyan lekérdező motort vagy SQL-motort kell felépítenie, amely nagyon kevés idő alatt valóban eredményes. Csak nem történik meg.
Tehát ennek a diának a következtetése az, hogy az adatbázisok stratégiai jellegűek, és fejlődnek, jobbá válnak. És minden bizonnyal ez volt az eset az Oracle és a Microsoft SQL Server esetében. Valószínűleg kevesen emlékszel vissza azokra a napokra, amikor az adatbázisok először létrejöttek, de én akkoriban fiú voltam. Az eredeti gondolat az volt, hogy egyetlen adatbázis létezik, és ez egy olyan fogalmi ötlet, amely egyáltalán nem gyökereződött be. Az IBM megkísérelte az AS / 400-at, hogy valóban legyen adatbázis-alapú fájlrendszer, de ez sem dominált. Megmarad az a tény, hogy az adatbázisok természetesen széttöredezettek. Valójában természetesen több példány van. Vannak méretezhetőségi problémák. Az adatbázis csak egy bizonyos méretre méretezhető, elismerhető, hogy a méret az évek során nőtt, ám korlátai voltak.
És voltak munkaterhelési problémák, a legfontosabb munkaterhelés az, hogy az OLTP és a nagy lekérdezési munkaterhelések egyszerűen nem kompatibilisek egymással. És lehetetlen volt olyan motort építeni, amely ezt megtenné. Amibe belefutunk, ami nagyon érdekes, nemrég találkoztam egy webhellyel, ahol több mint ezer különféle Oracle példány található. Pontosan nem emlékszem, hány DBA-vel rendelkeztek, de ha ténylegesen beszéltél velük arról, hogy hány ilyen adatbázist valósított meg egy DBA, ez tíz hasonló volt. Alapvetően az adatbázist szekrényként használták, és csak az adatokat dobták bele, mert legalább volt egy sémád és ez jobban szervezett volt, mint valaha a fájlrendszerben lenne, de senki semmit nem tett másnak, mint hogy alapértelmezett konfigurációt adott meg és állítsa be. laza.
Nem vagyok biztos benne, hogy ez jó ötlet volt-e. Ez furcsának tűnik számomra, hogy őszinte legyek, mert véleményem szerint, amikor adatbázisokkal dolgoztam, az adatbázisoknak látogatásra volt szükségük, és valamilyen módon tudnia kell, hogy pontosan mi folyik ott. És a rendkívül sok rendszer-függőség azt jelenti, hogy bizonyos típusú szolgáltatási szinteket feltétlenül teljesíteni kell, különben problémák merülnek fel.
Nemrég beszéltek, találkoztam különféle adatbázisokkal, amelyek állítják, hogy önhangoltak. Azok az oszloptárolók, amelyek a lekérdezés forgalmára vannak beállítva, nagyrészt önhangolódnak, mivel nagyon két választási lehetőséget kell választania az indexek szempontjából. De ezen a konkrét területen kívül az adatbázisokat be kell hangolni. Be kell hangolni őket, bizonyos relációs adatbázisokat, elsősorban azért, mert szörnyű sok tranzakcióhoz kapcsolódnak kapcsolódások. A csatlakozások drága tevékenységek. Ha nem a megfelelő mutatókat helyezte a megfelelő helyre, akkor a csatlakozás túl sok időt vesz igénybe, amikor nem kell.
Jelenleg az önhangoló adatbázisok csak azokon a területeken léteznek, ahol a munkaterhelés jól ismert. És tapasztalatom szerint a legtöbb vállalat nagyon kevés DBA-t alkalmaz, és azért van, mert drágák. És ezért jobb, ha megválthatja, amit a DBA tesz. Ez egy DBA tevékenysége, ahogy megértem. Telepítik, konfigurálják és frissítik az adatbázisokat. A frissítés, egyébként, nem feltétlenül triviális tevékenység. Annak érdekében, hogy frissítsen egy adatbázist, úgy értem, az a szabály, amellyel mindig dolgoztam, ne érintse meg, ha működik, és ha egy adatbázist frissít egy adott új verzióra, akkor tesztelési módban csinálja. először és utána mindent frissítesz. Még mindig ugyanazzal a verzióval foglalkozik. De valójában sok webhelyen találkoztam, erre nem kerül sor. Van, mondjuk, méltányos mértékű entrópia. Az engedélykezelés kérdés, attól függ, hogy milyen licencet kapott. ETL és az adatok replikálása.
Az adatbázis egyik trükkje, ha meg van osztva egy lekérdezési munkaterhelés, két példányt hozhat létre és replikálhat, és ez gyakran történik, ha az emberek szükség esetén a replikát forró biztonsági mentésként használják. Ezután a tárolás és a kapacitástervezés, ez egy DBA tevékenységének része, mivel az adatok természetesen növekednek, és ezt nyomon kell követni. És akkor meg kell terveznie a különféle hardverfrissítéseket vagy hardver-kiegészítéseket. Van egy hibaelhárítás, amely a legtöbb DBA számára fájdalmas tevékenység. Ahol valami rosszul fordul, és a biztonsági mentés nem működik pontosan tökéletesen, akkor fel kell fordítania az ujját, le kell szállnia, és meg kell próbálnia helyreállítani a naplófájlokat. Ez sokkal inkább megtörténik, mint gondolnám, jól emlékszem erre a történésre, de legalább tíz évig távol voltam a játékból, de emlékszem, hogy sokkal gyakrabban fordul elő, mint amire számíthattál volna. A teljesítményfigyelés és a hangolás egyfajta DBA-munka dobogó szíve. Biztonságot jelent a hozzáférés kezelése, a biztonsági mentés és a helyreállítás szempontjából is, olyan szoftvertesztelő rendszerek létrehozása, amelyek ésszerűen párhuzamosak egy élő rendszerrel. És az egész adat életciklusa. Tehát ez véleményem szerint a DBA által felsorolt munkahelyek listáján kívül helyezkedik el, bármi mástól, amelyet esetleg felkérhetnek. Működési dinamika. Az adat integritása és a szolgáltatás szintű kezelése a DBA elsődleges felelőssége. És általában kritikusak. És ennyit kell mondanom. Átadom Dez-nek.
Dez Blanchfield: Nagyon köszönöm. Kicsit szórakoztató, anekdotikus utazásra indul minket, miért szól az egész mai téma, amely ma szól, és kritikusabb, mint valaha. Nem olyan régen vettem részt egy olyan projektben, ahol áthelyeztünk egy állami kormányzati platformot, amelyet engedélyekhez és járművek nyilvántartásba vételéhez használtunk, és egy sor dolgot az adott témában, egy Fujitsu mainframe platformról, amely egy A + Addition nevű dolgot futtat, egy Solaris operációs rendszer, vagyis Unix, fut az Oracle és nagyon jó munkát végez rajta. És az a vélemény volt, hogy ez a dolog öregszik, és ideje áthelyezni valami másra. Nagyon szórakoztató volt az Unix futtatása a mainframe-en, nagyon stabil, nagyon biztonságos és furcsa módon az SDL platform, és éppen teljesen villámgyors. De a bölcsesség volt itt az ideje, hogy kiszálljon a nagygépről és mozogjon.
Ez a jelentős kihívás az összes rendszer és az üzleti logika, valamint az SQL környezet feltérképezése az alatta lévő adatbázisok számára, és megvizsgálva, hogyan tervezzük meg az új otthont. És végül elvégeztük az egyik ilyen dolgot, amely már néhány évvel ezelőtt van, de a Sun rack rendszer Starfire szervereinek egyik legfontosabb eleme. És ez valószínűleg a legnagyobb ón, amelyet meg lehet vásárolni a bolygón, és amely egy nagy dobozban és egy szimmetrikus multiprocesszoros szerverben él. Középkategóriás rendszer volt a világunkban. Az Unixot futtatta, az Oracle-t natív módon futtatta, és a következő nézet volt: „Mi lehet a baj?” Nos, kiderült, hogy nagyon sok.
Például abban az időben, és amiről már régen nem beszélünk, nagyon kézi folyamaton kellett átmennünk, hogy felfedezzük a mainframe platformon található oldalt, és áttekintsük. Különösen a tényleges adatbázis-környezet és az SQL logika. Tehát a nézet meglehetősen egyértelmű Oracle-to-Oracle lépésről, adatbázis-adatbázis áthelyezésről fog szólni; minden üzleti logika felbukkanna, az üzleti logika nagy részét beágyazott lekérdezésekbe és triggerekbe írták, és milyen nehéz lehet? De valami, amelynek több hónapot kellett eltartania, az nem egész évben telt el. Ahhoz, hogy fizikailag és manuálisan átlássam a Unix minden részét a mainframe környezetben, fedezze fel, hogy hol vannak az összes adatbázis és hány példány fut, és mi fut azokon a példányokon. Ez nem triviális gyakorlat volt, és végül elvégeztük háromszor annak érdekében, hogy megbizonyosodjunk arról, hogy mindent elfogtunk-e. Mivel minden alkalommal, amikor azt hittük, hogy olyan mélyre ásunk, amire szükségünk volt, a felszín alatt kiderült, hogy még több van.
A másik kihívás az volt, hogy mely példányok futnak és milyen állapotban vannak? Ez fejlesztési környezet? Ez tesztkörnyezet? Az integrációs folyamat része? Rendszerintegráció? UAT, a felhasználói elfogadás tesztelése? Termelés? Ez DR környezet? Mivel a nagygépek a nagy dolog, hogy felépíthetik ezeket a kis virtuális környezeteket, amelyeket mindannyian magától értetődőnek tekintünk, és mozgathatjuk a dolgokat. És ki kell dolgoznia, vajon ez a személy termelési szintű fejlesztést és tesztelést végez, vagy termelési tevékenységet folytat, vannak tényleges felhasználók ezen? Emlékeztetve arra, hogy ez a dolog valós idejű járművezetői engedélyek kiadását és gépjármű-nyilvántartásba vételét, valamint az emberek életének valóban fontos dolgát eredményezi.
És hosszú ideig tartott ahhoz, hogy biztonsági másolatot készítsen erről a dologról, így nem volt igazán ablakot a karbantartáshoz, hogy offline állapotba hozzuk a dolgot és megnézhessük mi történt. Nem volt olyan, hogy átirányítsák. Arra is kihívást jelentettünk, hogy nemcsak azt találtuk, hogy mely példányok futnak, hol és kinek, hanem aztán ki kellett dolgoznunk, hogy mely példányok futnak. És itt szinte elvesztettem a telek. Amikor rájöttem, hogy a termelési környezetnek két vagy három változata van, amelyek különböző szintű teszteléseken futnak, és ehhez nagyon kevés volt az eszköz és a szisztematikus megközelítés. Szó szerint bele kellett mélyülnünk a kódba és a futó példányba, és bizonyos esetekben kockáztatnunk kellett, hogy egy kicsit offline állapotba helyezzük valamit. Megérkeztünk ennek az egésznek a lényegéhez, feltérképeztük, és ahogy mondtam, nagyon kézi folyamat volt. És végül az egész ETL-váltást elvégeztük, egy helyről lerakva, a másikra mozgatva, és összességében működött. És olyan voltunk, rendben, funkcionális, nagyon örülünk neki.
De aztán számos nagyon komoly tömör téglafalat ütöttünk be. Különösen teljesítményproblémákat találtunk. És a nap ésszerű gondolkodása az volt, hogy egy nagyobb, jobb, gyorsabb és nehezebb hardverhez került, nincs ok, amiért az adatbázis szintű alkalmazásban rosszul teljesíthessen, szóval kezdjük máshol keresni. Tehát kétszer teljesen átalakítottuk a hálózatot. Minden útválasztó, minden kapcsoló, minden kábel, egyes esetekben az Ethernet-ről optikai szálra mentünk, frissítettük a szoftvert, javítottuk, megkaptad a nézetet. Alapjában véve kétszer újjáépítettük a hálózatot, azt gondolva, hogy ott a teljesítmény kérdése. És úgy nézett ki, és úgy érezte, mintha lenne. Különböző biztonsági rendszereken, különböző tűzfalakon mentünk keresztül. Megjavítottuk az operációs rendszert. A cuccokat egyik számítógépes pengéből a másikba mozgattuk. És jelentős időt töltöttünk annak infrastrukturális elemének megnézésével.
Aztán rájöttünk, hogy amikor leválasztottuk a szervereket, és futtattunk más alkalmazásokat is, akkor a hálózat nagyon jól működött. Tehát elkezdtük szétválasztani az operációs rendszert. Ugyanaz a kérdés. De érdekes, hogy a hálózati és az operációs rendszer szintje, az eszközök ott voltak, valójában viszonylag egyszerű volt számunkra összehasonlítani és tesztelni, és bebizonyítani, hogy ezek a darabok mindegyike működött. De akkor is, a Solaris SPARC hardverplatformján középkategóriában az eszközök nem voltak képesek az adatbázis-környezet diagnosztizálására. Tudja, feltérképezte, hogy az összes példányt át tudjuk-e hozni. Tehát ténylegesen fel kellett építenünk a saját eszközeinket, megírnunk és leülnünk, függetlenül attól, hogy maguk az adatbázis-eszközök voltak-e a natív szkriptnyelvekben, vagy shell-parancsfájlok sorozatát képezték, vagy bizonyos esetekben egy csomó C programot.
Végül néhány nagyon érdekes kérdéssel foglalkoztunk, amelyekben az SQL réteg alatti logika, a maguk az adatbázis-motorok kiderül, hogy amikor valami sajátos módon épült valami számára, ami az Oracle mainframe verzióján futott, a SPARC-en áttelepítették a Solaris-ba. Az Oracle verziója nem haladta meg azonnal ugyanazt a teljesítményt. Tehát ez elsősorban fájdalmas út volt számunkra, csak megtettük és megtaláltuk mindent, de most meg kellett diagnosztizálnunk az új termelési rendszeren, és ez a dolog ismét egy hónapig tartó migrációt adott ki közel egy évre. És egyszerűen arra a tényre jutott, hogy nincsenek körülötte az eszközök. Körüli dolgok, például a metaadatok leképezése.
Egy ponton szinte úgy döntöttünk, hogy szükségünk van egy Ouija táblára, mert így könnyebb lett volna véletlenszerűen mutatni és piszkálni. Egyszerű dolgok, például annak kiderítése, hogy ki férhet hozzá a régi rendszerekhez, és miért volt ez a hozzáférés. Kinek volt szüksége az új hozzáférésre és a megerősítésre, hogy valaki aláírja és megerősítse, és feltérképezze. Még olyan egyszerű, mint az adatbázis mérete sem volt konzisztens a két platformon. Építenünk kellett egy eszközt erre a feladatra, és összehasonlítani kellett az adatmennyiséget tonnatartalomban, nyers megabájtban vagy terabyte-ban az A rendszer és a B rendszer között, és részletesebben el kell osztani a teljesítmény és az előadó környezet körül. Újra új eszközöket kellett építenie. Nem volt egyszerű a polcon.
És ki is kapod ezt az egész üzenetet, amikor befejeztük a futtatás befejezését és stabilizálását, minden egyes darabja nagyon kézi folyamat volt, és csak úgy automatizálhattunk valamit, ha egy új eszköz vagy új szkript. És ha rendelkezzünk olyan eszközökkel, amelyek ma elérhetőek, az élet sokkal könnyebb és sokkal jobb lett volna. És milliókat takaríthatunk volna meg ezen a projekten. De azt hiszem, hogy arról, amiről ma beszélni fogunk, az a tény, hogy az eszközök már elérhetők, és ezek sokkal könnyebbé teszik az életet. Sok buktató továbbra is fennáll. Azon adatbázisok felfedezése, amelyek ott vannak, és melyik példányok mit futtatnak. Milyen állapotban vannak. Hány fut? Miért futnak? Hogy jól futnak. Támogatják őket?
Mindezeket sok szempontból magától értetődőnek tekinthetjük a megfelelő eszközökkel. De volt egy időszak ebben a konkrét anekdotában, amint mondtam, ahol nagyon sokan elvesztették sok hajot, valószínűleg tizenöt évet vettünk le az életünktől, és sajnáltuk, hogy az eszközök nem voltak ott most . És nagyon várom, hogy még sokkal többet meghallgassak erről ma, a mi vendégünk, Bullett. Tehát ezzel, Bullett, átadom neked, és várom, hogy meghallgassam, hogyan oldotta meg ezt a problémát.
Bullett Manale: Jól van. Jól hangzik. Eric, hadd vigyem át itt a diákat, és beszéljünk egy kicsit az igazi Ideráról, a cégről, mielőtt maga belekerülne a termékbe. Csakúgy, mint FYI, ez a különféle termékek portfóliója, amely elérhető.
Eric Kavanagh: A hangja nagyon meleg, tehát ha fejhallgatót használ, húzza fel kissé.
Bullett Manale: Nincs probléma. Így jobb?
Eric Kavanagh: Sokkal jobb. Elvenni.
Bullett Manale: Jól van. Tehát ma a Készletkezelőre fogunk összpontosítani, amely nyilvánvalóan igazodik ezeknek a témáknak a nagy részéhez, amelyeket megvitatunk. Csak szeretnék egy kicsit megérteni, hogyan jutott el ez a termék oda, ahol van. Napi szintű keresést kezdtünk a termékcsaláddal, egy Diagnostic Manager nevű teljesítményfigyelő eszközzel rendelkezik. Van egy Compliance Manager eszköz. Tehát rengeteg különféle eszköz van az SQL Server körül, és az engedélyezési célokból elkerülhetetlenül mindig feltesszük a kérdést: "Mennyi példányt kezel a szervezeten belül?" És az az érdekes, hogy soha nem tudtunk erre határozott választ kapni. Nem igazán volt fontos, kivel beszéltél. Mindig ilyen volt: "Nos, azt gondoljuk, hogy körül van ez a szám." Ilyen jellegű dolgok mindig jöttek be, és akkor ezt a folyamatot át kellett vetnünk, hogy pontosan kitaláljuk, mi az, hogy rendelkezésükre álltak az engedélyek a kezükben lévő példányok alapján.
Nyilvánvalóan gyorsan rájöttünk, hogy úgy tűnik, hogy sok fájdalom társul ehhez a sok DBA-ban. DBA-ként nyilvánvalóan az egyik dolog, amelyért felelősek, hogy ezt tudják, mivel az egyik dolog, amit meg kell tenniük, az licencszerződésük iránti aggodalom, a mi esetünkben a Microsoft és az SQL Server. Nyilvánvaló, hogy sok más különféle területtel is rendelkeznek, amelyekért felelõsek, de ez az egyik, ami egy ilyen nagy jegyjegy, DBA szempontjából, azaz az Ön általános felelõssége. Ezzel arra a következtetésre jutottunk, hogy olyan eszközre van szükségünk, amely megkönnyíti a DBA számára, hogy valóban megértse ezt a számot. Mivel van az SQL terjeszkedése, ha ezt meg akarjuk hívni, és ez többféle okból történik. Nem talán annyira az ellenőrzés, hogy ki telepíti a szoftvert, és milyen dolgok.
És a legrosszabb dolog, ami történhet, ha valaki megkapja az SQL Server másolatát, telepíti azt, tudás nélkül elkezdi vele dolgozni a vállalat más szervezeteinek vagy szervezeti egységeinek, majd a következő dolog, amit tud, talán az adatok nem kerülnek biztonsági másolatba, és azok a dolgok, amelyek történhetnek. Ahol most van egy másik problémád, olyan helyzetekben, amikor valójában elveszíti a kritikus adatokat, mert nem tudja, hogy a példány elsősorban létezik.
Az egyik dolog, amit tennünk kellett, az volt, hogy mondjuk, találjuk ki a felfedező darabot. És emellett képesek legyenek megszervezni és kezelni azt az információt, amelyet összegyűjtünk, logikus módon, amelynek értelme van az üzleti tevékenység alapján. És akkor nyilvánvalóan ebből következően képesek döntéseket hozni az információ körül, és képesek megtenni az ilyen dolgokat. Ez az, ahonnan az eszköz elindult, és honnan származott. Elmondhatom neked, hogy amikor rendszeresen beszélünk a DBA-kkal, valójában az a probléma, hogy nem tudjuk, hány példányuk van.
És vicces, mert az a kifejezés, hogy nem tudja kezelni azt, amit nem tud mérni, mindig olyan eszközöket hoztak létre, mint a SQL Diagnostic Manager, amelyek rendelkeznek, de valójában nem tud semmit kezelni, ha nem tudod Mégis ott van. Tehát ez az eszköz nagy része szintén az, hogy tudjuk, hogy megvan.
Ezzel a megjegyzéskel beszélve néhány nagyobb szervezettel vagy vállalati üzlettel az SQL Server használatával, az az érdekes dolog, amelyet sok srácgal találtunk, akikkel beszélgettünk, az volt, hogy valójában időbe állították az év folyamán, ahol fizikailag sétáltak egyik helyről a másikra, hogy megpróbálják meghatározni, hogy néz ki ez a szám. Elképzelhető, hogy DBA-nak elég jó összeget fizetnek azért, hogy fizikailag az egyik gépről a másikra sétálhassanak, ami meglepően olyasmit fog hallani néhány nagyon nagyvállalattól, amelyeket nem fogok megnevezni. De egyfajta érdekes szempont, hogy egy év két hétét ilyen típusú gyakorlatok elvégzésére fordíthatják, hogy megtudja, helyes-e az engedélyek száma.
Ez mind kapcsolódik ehhez az eszközhöz, és azzal, hogy miként segít, de ahogyan megválaszoltuk, az az SQL Server számos tulajdonságán alapuló felfedezés képessége volt. És tehát az első kérdés az, hogy mire utal, vagy mit próbál először megnézni? Úgy tettük, hogy azt mondjuk, hogy csináljuk IP-tartományonként, vagy megtehetjük magának a domainnek a tagságával, a tartományba tartozó számítógépek tekintetében. Ilyen módon kezeltük ezt a részt, csak hogy elmondhatjuk, hogy erre a területre koncentrálunk a felfedezés szempontjából.
És akkor a másik része ezen a jellemzőken, a portokon és más dolgokon, a WMI regisztrációs kulcsokon és az ilyen jellegű dolgokon alapul, összegyűjthetjük és meggyőződhetünk arról, hogy az SQL valószínűleg fut és telepítve van-e az adott példányra vagy az adott környezetre. Ez nyilvánvalóan sokkal jobb módszer, mint a tornacipő vagy a cipő expressz módszere. A remek dolog az, hogy az összes információt, amelyet a példányról gyűjtünk, egy adattárban tároljuk, és a környezet változásakor megváltozhat. Nem csak arról szól: „Hé, van egy példány, itt van egy lista, amit találtunk”, hanem ez a DBA, vagy a példányokat kezelő személy, mivel képes meghatározni, hogy a készletnek ezt a részét meg akarja tenni, majd mikor nem része a készletnek, hogy le lehessen bontani az adott példányt. Tehát az SQL Server-példány teljes folyamatának életciklusa valóban könnyen megérthető az eszközön belül.
Miután felfedeztük az eseteket, mit tegyünk azután? A másik dolog a példányra vonatkozó sok információ, nem akarom, hogy manuálisan szerezzem meg, és táblába kell helyezni, vagy ilyen dolgokra. És ez egy másik dolog, ami érdekesnek bizonyult a DBA-kkal való beszélgetés során a leltár folyamatáról és az engedélyeztetésről, az, hogy meglepődne, hány DBA-val beszéltem, amikor azt kérdezte tőlük: „Hogyan tartja fenn a leltárát?”, És beszélünk a DBA-kkal, ami a valóban ironikus része, hogy ezt tartják és követik minden statikus táblázataként. Mint mondtam, nagyon ironikus, ha erre egy percre gondolsz. De ez sok esetben történt, és sok szervezetnél is így van, hogyan kezelik ezt. Hogy őrzik ezt? Ez egy Excel-táblázat mester másolata, amely lebeg, és rendszeresen frissíteni kell.
Ezek azok a dolgok, amelyek kihívást jelentettek, így regisztrálva azt a példányt, és a nyilvántartás részévé téve ezt megteheted, és felveheted az információkat. Automatizálhatja, függetlenül attól, hogy részévé válik-e a leltárnak, a verziónak, a kiadásnak; a többi dolog, amit vele végezhet, manuálisan hozzáadhatja azt a listát vagy Excel-táblázatot, amely rendelkezik. Ezt az SQL Inventory Manager nevű eszközbe importálhatja. Ha már van olyan példányok kiindulási pontja, amelyekben magabiztosnak érzi magát, akkor importálhatja ezeket a példányokat, majd a kezelt készletének ezt a részét a terméken belül létrehozhatja. Ha már megvan a példány, és ha tudjuk, hogy ott van, akkor az lesz, oké, rengeteg információt kaptunk, amelyet fel tudunk használni, ha tudjuk, hogy az adott példány ott van, kimegyünk és összegyűjtjük az információkat.
És sok információra lesz szükség, nem csupán az engedélyezési célokra. Nagyon sok felhasználható nyilvánvalóan csak annak megismerésére, hogy hol vannak a dolgok, és ezen információk között kereshetünk, miután megszereztük őket. De a legfontosabb dolog a szerver, maga a hardver. Annak megértése, hogy milyen típusú gép, talán a modell vagy a gyártó, a memória, a memória mennyisége, akár fizikai, akár virtuális gép, és különösen a fizikai aljzatok vagy magok, valamint a CPU-k és az ilyen típusú dolgok száma.
A magok számát tekintve, különös tekintettel az SQL Server-re, az licenszelés módjának ismerete az SQL újabb verzióiban most egy magonkénti számítás, amely valóban nagyon fontos részé válik, és nem minden, ami van hogy menjen ki, és valójában menjen ásni. Miután a példányt azonosítottuk, megadhatjuk ezt az információt, és kivonhatjuk azt, és lehetővé tehetjük, hogy megnézze és megértse, és nyilvánvalóan ki is használhatja azt.
A következő réteg lefelé van abban a példányban, amelyben nyilvánvalóan nagyon sok különbözik az SQL Server példánytól, legyen az szabványos, vagy vállalati, vagy akár kifejezett ebben az ügyben, vagy az SQL Server ingyenes verziója. Annak megértése, hogy milyen alkalmazások kapcsolódnak az adott példányhoz, és ez automatikusan megtehető. Képes megérteni a konfigurációs beállításokat és az olyan dolgokat, valamint egyéb információkat, amelyek az SQL Server példányához kapcsolódnak.
Ezután lejut a tényleges adatbázishoz, és megnézheti a konfigurációs beállításokat, az adatokhoz kötött helymennyiséget, ahol található, az összes ilyen adat automatikusan kitöltődik, és ez óriási időmegtakarítást jelent. És ismét, mivel dinamikusan megy ki, és napi rendszerességgel azonosítja az új példányokat, ez egy élő dolog, mely a készletével rendelkezik. Ez a termék célja az, hogy így készítse el, az legyen, hogy dinamikusan változóvá váljon.
Most, amikor mindezek az információk elérhetővé válnak számunkra, és ezeket az adatokat be tudjuk vinni, akkor valóban értelmes bizonyos esetekben megkezdeni a saját metaadatok létrehozását az ezekhez az esetekhez társítva, és hogy a metaadatok ilyen módon hozhatók létre. igazodik az üzleti vállalkozáshoz.
Tehát ha a példányokat földrajzi helyzet, vagy alkalmazás-tulajdonosok, vagy a DBA-tulajdonosok, vagy bármi más szerint csoportosítják, akkor az lehet, hogy hogyan szeretné csoportosítani ezeket a példányokat, hogyan logikusan szeretné értelmezni ezeket a példányokat, akkor van ilyen az eszköz két területének két olyan része, amely megadja ezt a képességet.
Az első a példánycímke vagy egy címke létrehozásának képessége. Ami alapvetõen asszociációt hoz létre a szerver, a példány vagy az adatbázis számára, hogy nézeteket készítsen és válaszoljon a napi szinten felmerülõ kérdésekre, ez valóban segít abban, hogy megbirkózzon azzal, ami van, mit kezdi, és hogyan kíván tovább lépni ezzel az információval.
A másik dolog, amit nálunk leltármezőknek vagy egyéni leltármezőknek nevezünk, és ezek inkább az információ részleteinek kiszerelésére vonatkoznak, amelyekbe be lehet mélyíteni, például az adatbázis rétegre, amelyről dönthetnék, hogy hozzáadom egy legördülő listát, amely az összes DBA-t, és el tudom mondani, ki az, aki felelős az adatbázisért, attól függően, hogy milyen helyzetben van, vagy akármi is legyen, függetlenül attól, hogy melyik adatbázis az, aki felelõs azért, hogy ezt ki tudja választani, hogy tudjam, hogy ők az, akik felelõsek és nagyon egyszerűen azáltal, hogy beleásod a leltárba.
Tehát ezek az információk nagyon értékesekké válnak, főleg ha nagy környezetben van, mert csak segít megérteni ezt az információt és megismerni, mi van és hogyan csinálod.
Tehát hadd menjek tovább, és váltsak át a következő diára itt. Most azt mutatom meg, hogy az összes ilyen információ, amelyet összegyűjtünk, az összes információ és adat, amelyet összegyűjtünk és metaadatokat alkalmazunk, lehetővé teszi számodra, hogy sokkal könnyebb és gyorsabb döntéseket hozzon, amikor nyújtsa be a Microsoft licenceit a vállalati mennyiségi licencekben vagy a Microsoft szoftverbiztosításában.
Ez megkönnyíti, hogy ezt megtegye, ahelyett, hogy rengeteg kézi adatgyűjtést kellene tennie, meg kellene tennie, sok információ kézi összegyűjtését kellene elvégeznie, amely valójában csak sokkal jobbá teszi a folyamatot. Ez tehát ez a termék egyik megbízása, valamikor, hogy megkönnyítsék a DBA-k számára az engedélyezéssel kapcsolatos döntések meghozatalát.
A másik dolog, amit - a DBA-kkal beszélve - nagyon gyorsan felfedeztünk és megtanultunk, és ez - és ez egyfajta visszatér a korábban tárgyalthoz - az SQL Server környezetében 300 példány lehet, de valójában csak egy alkészlet létezik azok közül, amelyeket valóban teljes mértékben figyelnek és kezelnek egy hagyományos teljesítményfigyelő típusú eszköz segítségével.
Tehát ha elmész, és valóban leül a DBA-val, és azt mondja: „Nézd, tudjuk, hogy megvan ezek a 20 példány vagy a 300 példánya, amelyeket megfigyelünk ezzel az eszközzel, amelyet annak ellenőrzésére terveztek, és megfelel az Ön SOA-k és figyelmeztetések és mindenféle jó dolog. ”Azt is találtuk, hogy ha megkérdeztük:„ Akkor hát mi van a többi 280 példányoddal? Érdekel ezekről? ”És ők is törődnek velük, de csak nem akarnak feltétlenül befektetni azért, hogy figyelemmel kísérjék azokat a mélységszintet, amit ezekkel a példákkal meg lehet tenni, szemben a 10-es vagy 20-as valóban, valóban kritikus termékpéldányok.
Tehát az egyenlet ezzel az eszközzel a másik része az, hogy segít abban is, hogy megbizonyosodjon arról, hogy egy alapszintre vonatkozik-e az eset egészsége szempontjából. Most nem fogja megmondani, hogy van-e patthelyzete, vagy aki a patthelyzet áldozata. Nem az kell, hogy magukra a szekciókra és a lekérdezések részleteire kerüljenek. De ugyanakkor továbbra is tudatja velünk, hogy hé a szerver le van töltve, vagy hé a kötet megtelik, vagy biztonsági másolatot kell készíteni az adatbázisról, ez egy fontos része a DBA-nak.
Tehát az ilyen jellegű dolgok határozottan továbbra is fontosak, és ezzel az eszközzel egyfajta eszközzé tette számodra a valóban kritikus példáit, amelyekhez nagyon sok, sok érdekes kötődés tartozik, ha elmennek le kell tudnod azonnal. Lehet, hogy magasabb szintű megfigyelés alatt állnak, és képesek megtenni az ilyen jellegű dolgokat, míg ezzel képesek lesznek felvenni a környezethez hozzáadott új példányokat, és ellenőrizni, hogy számvitelre kerülnek-e, és győződjön meg arról, hogy az egészségügyi ellenőrzések ezen alapszintjei kialakításban vannak.
Tehát egy ilyen dióhéjban szól az Inventory SQL Import Manager. Most megmutatom neked egy demonstrációt. Mielőtt ezt megtennénk, egyszerűen gyorsan megmutatom neked, hogy ez az itt található építészeti dia, és csak azért, hogy megmutassuk ezt, az általunk kezelt SQL példányokat, mindent felfedezve az SQL 2000-től egészen az újig az SQL verziói.
Tehát meg tudjuk csinálni anélkül, hogy valaha is kellene ügynököket telepíteni magukba a példányokba. Gyűjtőszolgáltatáson keresztül csináljuk, és megy ki, és összegyűjti ezeket az információkat, és lerakatba helyezi, majd a Tomcat webszolgáltatás felhasználói felületének konzoljáról képesek leszünk ezekre az adatokra lépni és megnézni azokat. Tehát ez elég egyszerű építészet.
Megyek, átváltom, és ténylegesen magába foglalom magát a terméket, hogy érezze magát rajta, megértse, hogyan működik. Tehát a legjobb módszer erre az, ha elsőként ismertetjük önmagát a felülettel. Ez egyfajta műszerfal, amelyet itt nézünk.
Jelenleg látom, hogy az irányításom alatt álló példányok száma nem olyan sok. De a hátsó zsebemben sem található teljes adatközpont. Tehát hat példányom van, amelyeket itt látunk. Most azt mondta: én vagyok, azt fogom tenni, hogy végigmenem a felfedezés folyamatán, és megmutasom, hogyan működne.
Most az első dolog, amit megtenne, az adminisztráció szakaszban megadhatja, hogy miként szeretné felfedezni a példányait. Ön képes lesz arra, hogy ezeket az információkat ide és újra megtegye, amit meg lehet tenni egy sor IP-cím segítségével. Mutathat egy domainre vagy aldomainre, és csak azokon a gépeken tudja végrehajtani azokat a gépeket, amelyek a tartomány tagjai, és elvégezheti azokat az ellenőrzéseket, amelyekre számos különféle jellemzőt választhat, amikor az SQL ellenőrzést fut.
Akkor, ha ezt megtetted, és automatizálhatod napi szinten történő futtatásához az adatok gyűjtése érdekében. Szükség esetén ad hoc alapon is megteheti. De ha elindítja ezt a felfedezési folyamatot, akkor az látni fogja, amikor átmegy az itt található példánynézetre. Van egy Felfedezés lap, és a Felfedezés lap megmutatja azokat a példányokat, amelyeket a közelmúltban fedeztek fel. Tehát a mi esetünkben van egy számunk itt. Amit megyek előre, és megyek előre, és hozzáadom azt, amelyet példaként fogunk használni. Tehát ebben az esetben ez egy chicagói eset, igaz? Megyek, és hozzáadom ezt a példát a leltárhoz.
Rendben, és itt áttekintünk egy-két dolgot. Csak megyek előre, és látni fogja, hogy beállíthatjuk a hitelesítő adatokat. A hitelesítő adataimnak jónak kell lennie ott. Megyek előre, és észre fogod venni, hogy ha akarom, átruházhatom ennek tulajdonjogát. Meg tudok határozni egy helyet is. Most magát a helyet is hozzá lehet adni, és nyilvánvalóan emlékezni fog rá a következő alkalommal is.
Ismét hozzákapcsolhatom ehhez a címkéket a metaadatok szempontjából, és azt, hogy hogyan szeretnénk az SQL e példányait, különösen ezt, az összes vödörbe helyezni, ahova be akarjuk helyezni. Tehát van néhány aktuális címke, népszerű címke, így megnézhetünk egy csomó különböző címkét, amelyeket talán már beletettem. Csak véletlenszerűen válogatom ezek közül néhányat, és ezt alkalmazhatjuk.
Tehát most, ha megyek, és hozzáadom ezt a leltárhoz. Most, hogy hozzáadtuk, láthatjuk, hogy ez a kezelt nézet alatt jelenik meg, így itt láthatja a felsorolást. Tehát tudod, hogy ez az első lépés, és amit éppen megmutattam neked, az az út, amellyel főként hozzáadja azokat a példákat, ahogyan napi szinten átmenne. Bizonyos esetekben azt mondhatja, hogy tudod, mi van, ha az SQL szerver vállalati kiadása, amelyet automatikusan hozzá akarok adni a készlethez? Nem kell manuálisan mennem, és ezt választanom.
Jocelyn: Nagyon gyorsan félbeszakítlak téged. Nem látjuk a demót.
Bullett Manale: Nem igaz?
Jocelyn: Nem.
Bullett Manale: Nos, ez nem jó, lássuk.
Eric Kavanagh: Ha a bal felső sarokba lép, kattintson a Start gombra, majd kattintson rá.
Bullett Manale: Ó, oké.
Eric Kavanagh: És most megosztom a képernyőt.
Bullett Manale: Sajnálom. Ja.
Eric Kavanagh: Ez rendben van. Jó fogás ott, Jocelyn producer.
Bullett Manale: Jól van, így jobb? Most látod?
Robin Bloor: Igen, valóban.
Bullett Manale: Rendben, szóval csak sétáljunk át gyorsan, ahol igazán voltunk. Megtaláltuk a korábban felfedezett példányokat. Most adtam hozzá a chicagói példányt, tehát amit most látsz, az itt most szerepel. Vegye figyelembe, hogy ez már rengeteg további információt tartalmaz. Ha rákattintunk maga a példányra, akkor látni fogja az összes olyan információt, amelyet már összegyűjtöttünk a példányról. Most itt található az összes ott található adatbázis felsorolása. Láthatjuk az adatbázisok megoszlását méret és tevékenység alapján, melyik méret és aktivitás jellemzi a legtöbbet.
Ismét azt is megmondhatjuk Önnek, hogy a denevérrel milyen alkalmazásokat látunk futtatni az adott példányon, az adott példányon futó munkaterhelés alapján. Tehát nagyon kedves ezt automatikusan megtenni. Nem kell bemennem, és az alkalmazást az előfordulási arányhoz kötnem. A látása alapján lakhatjuk ezt. Most, ha manuálisan szeretne hozzáadni egy alkalmazást, feltétlenül megteheti. De ez csak egy jó módszer arra, hogy megmutassuk a példány társulását az adatbázishoz, vagy, sajnálom, az alkalmazáshoz.
Azt is észreveheti, hogy a képernyő jobb oldalán azonnali összefoglalónk van, alul pedig szerverösszefoglaló. Tehát itt a példány kulcsfontosságú információiról beszélünk, tudva a verziót, és nem csak, tudod, az SQL Server 2012-et, hanem a tényleges verziószámot is, amely magában foglalja és elmondja nekünk, hogy milyen gyorsjavítások vannak hozzákapcsolva, milyen szervizcsomagok Nagyon fontos tudni. Nyilvánvalóan fontos a memóriaigény. Minden ilyesmi, függetlenül attól, hogy csoportosul-e, és ezt az információt nem kell beletennem - már összegyűjtik és összegyűjtik, és ha egyszer megtudjuk, hogy ez egy felfedezett példány, akkor ez része lesz a készletünknek.
A másik dolog, amit itt látni fog - és meg fogja mutatni - ez a példány nézet alatt található. Megvannak ezek az attribútumok, amelyekről már korábban beszéltünk, az egyedi attribútumok, amelyek hozzáadhatók. Tehát hozzáadhatunk nyílt típusú szövegmező mezőket, igen vagy nem, tudjuk, egy milliárd féle választás szempontjából. Még legördülő listákat is készíthetünk. Ezt megteheti az adatbázis példányán vagy a kiszolgáló szintjén.
Ezután, ha egy kissé tovább gördítünk le, láthatjuk az összes kapcsolódó információt maga a kiszolgáló felé. Tehát tudod, hogy minden ilyen cucc nyilvánvalóan nagyon, nagyon hasznos, mert mindent összegyűjtöttek és összegyűjtöttek, és ott állnak nekünk, amint meghozjuk ezt a döntést, hogy a készletünk részévé válik. Itt megmutathatjuk néhány különbséget a CPU-k tekintetében, a logikai és fizikai viszonyok számát, valamint a memória mennyiségét. Tehát valóban nagyon jó és rengeteg információhoz jut, anélkül, hogy sok munkát kellene elvégeznie.
Most a másik része ennek, amint mondtam, az, hogy ezeket az adatokat szerver szintű példányon gyűjtjük össze. Ha le is megyünk az adatbázisra, láthatjuk, hogy ezeknek a dolgoknak a nagy része megoszlik nekünk is. Tehát ha elmegyek a megfelelési adattárhoz, ebben az esetben mondhatnám, jól tudja, hogy ezzel foglalkozik, ez egy megfelelési adatbázis, amelyhez a megfelelési szint vagy a szabályozási követelmények társulnak, és lehet, hogy mondjuk, SOX vagy PCI megfelelés. Tehát megválaszthatom, hogy mely adatbázisokhoz kapcsolódik azok a megfelelőségek, amelyeket ki kell töltenem, vagy megbizonyosodom arról, hogy fenntartom-e ezt a szabályozási követelményt.
Tehát ez a fajta cucc nagyon hasznosnak bizonyult a DBA-k számára, mert van egy olyan hely, ahova központilag eljuthatnak, hogy az összes kapcsolódó metaadatot könnyen megőrizzék a környezetükben, és megtehetik, hogy, amint mondtam, megfeleljenek üzleti vállalkozásuknak, mivel ők ' üzleti tevékenységet folytatnak. Tehát, ha az eddigiekre kattintunk, amiket látunk, akkor nyilvánvalóan nagyon jó áttekintést kap a példányról, ha belemegyek.
Keresni is tudok, tehát azt mondtam, hogy keressük meg a megfelelőségi lerakatot a leltáromban. Akkor itt láthatja, hogy ezeket a dolgokat keresek meg, és azonosítani tudom őket. Azt mondom, hogy nem vagyok biztos benne, mi, a go gombom nem működik ott. Oké. Lássuk, próbáljuk meg újra. Oda megyünk. Tehát akkor láthatnánk egy bontást, ahol látunk bármit, amellyel megfelelünk, és be tudok mélyülni, és láthatom is ezt a szempontot. Tehát van egy nagyon gyors és egyszerű módja annak, hogy belemerüljön ezekbe az adatokba.
Most, ahogy korábban említettük, nagyon sokféle módszer van metaadatok létrehozására a példánykiszolgálóra és az adatbázisra. Ennek másik része az, hogy kihasználhatja azt, ahogyan azt csoportosítod, és ahogyan társította. Felfedezzük a felfedező nézetet, csak ezt tehetjük meg. Azt mondhatjuk, szeretnék egy adatbázist hely szerint számolni. Tehát az adatbázisok száma a támogatott környezetek minden helyén. Vagy talán a tulajdonoson alapul, aki birtokolja azokat a példányokat, amelyek ott vannak, esetleg a példányszám szempontjából. Tehát látni fogjuk ezt. Tehát kap egy igazán jó és egyszerű módszert, hogy festse fel ezeket a képeket az Ön számára bármilyen kérdés alapján, hogy az adott időben megpróbál válaszolni.
Akkor azt az információt, amellyel a kívánt módon hozta létre, exportálhatjuk PDF-be vagy más formátumba, hogy kihasználhassuk és elküldhessük kollégáinknak, vagy megtehessük, amire szükségünk van. Tehát tudod, hogy képes lennél ilyen dolgokra. Térjünk vissza - elvesztettem? Oda megyünk. Rendben, remélhetőleg ez értelme annak, amit eddig beszélek. Most, hogy az összegyűjtött adatokat, mindez nyilvánvalóan számos okból - licencbe vétel és bármi miatt - valóban létfontosságú.
Az utolsó dolog, amit csak megemlíteni kell, hogy itt megyünk erre az adminisztrációs szakaszra. Itt is konfigurálhatja az e-mail címét és a riasztását, és meg tudja győződni arról, hogy azoknál a dolgoknál, amelyekről valóban tudni szeretne, ezeket beállíthatja. Tehát beállíthatunk e-mail figyelmeztetéseket, beállíthatjuk bizonyos dolgok bekapcsolásának és bizonyos dolgok kikapcsolásának képességét, majd meghatározhatjuk, ki fogja kapni ezeket az e-maileket, és feliratkozva ezekre a figyelmeztetésekre, társíthatjuk azokat, akiket szeretnénk hogy legyen, aki tudni akarja az ilyen fajta dolgokat.
De amint már korábban mondtam, ez egy nagyon jó módszer a végrehajtáshoz, és legalább nyugodj meg abban, hogy tudod az egész vállalati SQL példányt - mi van velük, és ügyelj arra, hogy az optimálisan működjön, még akkor is, ha nem Nem döntött úgy, hogy beruházást végez egy nagy teljesítményű teljesítményfigyelő eszközre az adott példány kezelésére. Ez fedezni fogja Önt, mert nagyon megfizethető mód a kimenetre, és sok esetben képes elvégezni ezeket a leltárokat, és képes lenni egyfajta nagyon széles típusú általános szintű felügyeletre annak biztosítása érdekében, hogy megszerezte a nyugalmat és tudja, mi folyik itt.
Tehát remélem, hogy van értelme annak, ahogyan leírtuk és megmutattuk nektek. Azt hiszem, ebből a szempontból továbbléphetek, és tovább beszélhetnénk.
Eric Kavanagh: Nagyon jól hangzik. Tehát Robin? Dez? Bármi kérdés?
Robin Bloor: Nos, vannak kérdéseim. Valójában nagyon érdekes, úgy értem, csak azt akartam megtenni, hogy nagyjából mindenütt voltam, nem csak a DBA-k között, hanem a hálózati srácok, a tároló srácok, a virtuális gépkezelő srácok között, az összes táblázatok kidolgozása.
Eric Kavanagh: Így van.
Dez Blanchfield: Tudod, hogy ez az, akkor tudod, hogy ez rendben van, amíg a számok el nem kezdenek mozogni. Amikor a számok mozogni kezdenek, tudod, hogy bajba kerülnek. Tehát a kérdés, amelyet most nagyon érdekel, és tudom, hogy neked nehéz lesz megválaszolnia, de mi van, ha olyan helyre megy, ahol a táblázatok működtetésére nincs itt ilyen, akkor tegyük fel, hogy a DBA-k nagyon okos srácok és így tovább, és így tovább, Ön szerint milyen megtérülést érne el valami ilyesmi végrehajtásával? Van számod erről, vagy bármilyen iránymutatás?
Bullett Manale: Nehéz megmondani, mi a megtérülés, mert a környezet kicsit más lesz. Nyilvánvaló, hogy minél nagyobb a vállalkozás, annál nagyobb a környezet, nyilvánvalóan annál inkább lesz a ROI, ha most, manuális módszereket használnak.
Tudom, hogy beszélek számos - amikor azt mondom, hogy nagy szervezetek ezrei és ezrei alkalmazottak között, és valószínűleg ezrek példáinak is -, ahol vannak olyan emberek, ahol ezt megmutatom nekik, és azt mondják, hogy ez két hetes időm vissza. Ezt már egyszer mondta nekem. Tehát nehéz megmondani a vásárlás tényleges dollárösszegét tekintve, de ez számottevõ, ha van a környezet.
Mint mondtam, nagyon következetes, az emberek, akikkel vagyok, a legtöbb ember, akivel beszélek, ezeket a dolgokat táblázatokban tartják. Tehát ez csak egy nagyon, nagyon szubjektív dolog, mivel minden környezetben ez kissé különbözik attól, hogy hogyan hajtják végre az engedélyezést, és hogy hogyan teljesítik a Microsoft általi engedélyezést. Ennek egy másik része, ez tényező. De ha évente vagy háromévente igaz valós munkát kell végezniük, azt hiszem, három év múlva a Microsoft számára ezt megteszik, azt akarják, hogy legalább háromévente igazítson.
Akkor megismerheti annak jelentős értékét, és tudja, hogy ez csak valami, ami sokkal könnyebbé teszi. Mivel egy dinamikus dolog, amely állandóan változik, egy kicsit több érvényességet ad a versekre nézve is, és mi sem igazán frissítettük a táblázatot hat hónapban vagy egy évben. Tehát milyen gyakran frissíti a táblázatot, egy másik kérdés, hogy megértsük, mi a válasz a megtérülésre.
Dez Blanchfield: Igen, az SQL licencre gondolok, ennek licencbe adása csak egy átkozott rémálom, de ez különösen rémálom, mert a licenc nem ugyanaz a Microsoft és az Oracle, és bárki más között, aki adatbázis-tevékenységeket végez. Ha valójában a táblázatokon tartja a dolgokat, ami általában úgy történik, mint ami valójában megtörténik, akkor tudja, hogy az engedélyezési idő körül megy, mielőtt ténylegesen észreveszi, és nincs olyan adata, ha tudod, hogy mire gondolok, hogy könnyen elérhesse ezt az információt.
Mindenesetre, amint rámutatott, dinamikus és személy szerint fogalmam sincs, mert soha nem kellett tárgyalnom a Microsoft-lal, így fogalmam sincs, de feltehetően vannak olyan adatbázisok, amelyekben az emberek elég gyakran levonják a teszt adatait és azt gondolom, hogy ezek egy tövis az Ön oldalán, ha licenccel jár. Te vagy az-?
Bullett Manale: Igen, igen. Ez a helyzet azért, mert sokszor elfelejtik ezeket a dolgokat, és akkor elkezdenek kipróbálni, oké, jól oké, megvan a magunk licencelése, hogy ki kell számolnunk az egyes példányok magjainak számát, és Nem tudom, hogy a hardver bölcs vásárlása szempontjából valószínűleg nagyon jó hardvert is vásárolhat, akkor ha nem a hardvert használja úgy, ahogyan azt ki kellene használni, akkor túlfizet, mert fizetni a központi árazásért, ha ezeket a magokat nem használják fel, így ez problémát jelent.
Tehát az SQL minden egyes verziója különbözõ módon alkalmazza az engedélyezést, ami még kissé megzavarja. Tehát van néhány kihívásod ezzel kapcsolatban, és ez tehát nagy része annak, hogy miért nagyon hasznos ez az információ, mert meg tudjuk mondani, hogy melyik verzióról van szó, nyilvánvalóan megmondhatjuk, hány magod van, ha az SQL régebbi verziói ez volt a socket árazás, ezt továbbra is nyilvánvalóan megmutathatjuk. Tehát egyszerűvé teszi a rutin sokkal egyszerűbbé tételét, amelyet át kell mennie, amikor eljön az ideje, hogy igazítsa ki ezeket a dolgokat.
Dez Blanchfield: Egy dolog, ami eszembe jut nekem, ó, sajnálom …
Robin Bloor: Rendben, menj Dezbe, egy esetlegesen irreleváns kérdést akartam feltenni.
Dez Blanchfield: Csak valami nagyon gyorsan, miközben a témája jelenleg aktuális - sokkal inkább felhős környezeteket fogadunk el, és ha ezt saját adatközpontunkban, saját környezetünkben működtetjük, körbejárnak és megtalálják, felfedezni a dolgokat viszonylag egyszerű.
Hogyan, hogyan kezeljük a forgatókönyvet, amikor három adatkészlettel, két felhővel rendelkezhetünk, és ezeknek a környezeteknek a láthatósága tűzfallal van ellátva, és gyakran van adatkészlet egy cső vagy VPN végén. Van-e felfedezés az elejétől, vagy kell, hogy megkezdjük a portok megnyitását, hogy bizonyos környezetekben átvizsgálhassunk egyfajta felhő és olyan helyiségek között, ahol ez a platform fut?
Bullett Manale: Igen, lenne néhány szempont a kikötők szempontjából. Tehát sajnos azt szeretném mondani, hogy áttör minden ilyen környezetet, de van néhány különféle lehetőség, amit ezzel megtehetsz. Nyilvánvaló, hogy ha valami hasonlót csinál az Amazon EC2-hez, akkor csak a kapcsolaton keresztül kell ehhez a környezethez hozzáférnie, feltételezve, hogy a portok nyitva vannak, és meg tudja adni az IP-címeket vagy az ahhoz társított domainjét, és elindulhat. a gyűjtemény és a felfedezés indítása.
Tehát az ilyen típusú környezetekben ez valójában nem jelent problémát; ez a közelebbi típusú környezet, például az RDS, és ahol csak magát az adatbázist kapja meg, ahol egy kicsit nagyobb kihívást jelent az ilyen típusú információk megismerése és felfedezése.
Dez Blanchfield: Tehát ebből következik, vannak adatbázisok és adatbázisok. Tehát például a régi jó időkben az a tény, hogy nagyon-nagyon nagy adatbázis-motorral rendelkezik, mint például az anekdotának, amelyet elől megosztottam, ahol csak egy hatalmas platform van, és csak adatbázis-készítéssel rendelkezik. Manapság az adatbázisok mindenbe be vannak ágyazva, valójában olyan, mint kettő vagy három csak a telefonomban fut az alkalmazások mögött.
Milyen kihívásokkal szembesül olyan forgatókönyvek, amelyekben a környezet a Lotus Notes alkalmazásból származik, az alkalmazások mögött vannak, a SharePoint a különféle internetes adatbázisokkal és így tovább? Alapvetően mindent a hátsó adatbázis adatbázis hajt. Milyen dolgokat látsz odakint, és milyen kihívásokkal szembesül az emberek, akik csak megpróbálják feltérképezni az ilyen fajta világot, és mit eszközöl számukra?
Bullett Manale: Nos, úgy értem, hogy az a helyzet, hogy amit mondtál - mindennek szüksége van egy adatbázisra, tehát sokszor valószínűleg nagyon sok olyan adatbázis található be a környezetbe, amelyet a DBA maguk is bevezetnek még akkor sem veszik észre, mert általában nem túl nehéz az SQL szervert telepíteni a környezetbe.
Ez az eszköz azonosítja az expressz adatbázisokat is, azaz az SQL Server ingyenes verzióit. Elég vicces, ha ismét beszélgetünk a DBA-kkal, nem kapnak következetes választ azzal kapcsolatban, hogy érdekli-e őket a szabad adatbázisok. Ezen alkalmazások közül sok, amelyekről beszélt, az adatbázis ingyenes verzióját fogják használni. De maguknak a szervezeteknek más a hozzáállása abban a tekintetben, hogy ki felelős az adatbázisért, attól függően, hogy kivel beszélsz.
Néhány DBA-val, amivel beszélek, arra gondolok, hogy legutóbb, amikor az SQL Server PASS-en jártam Seattle-ben, felteszem a kérdést: „Vigyázz az expressz adatbázisokra?”, És körülbelül ötvenötven volt. Néhány ember a DBA-ról akart tudni róluk, mert úgy érezték, hogy felelősségi körükbe tartoznak még azok a kifejezett adatbázisok is, amelyek még mindig tartalmazhatnak kritikus információkat; továbbra is át kell menniük a biztonsági mentés folyamatán, és továbbra is gondoskodniuk kell arról, hogy minden dolog egészségügyi szempontból működjön rájuk. Ugyanúgy fontos, ha nem is fontos, csak tudni, hogy léteznek.
Míg az emberek másik fele a következő: „Hé, nem vagyunk felelősek azért az adatbázisokért, és bármi, amit rájuk raknak, vigyázni kell az embertől, aki telepítette őket.” De azt mondanám, hogy általánosságban Azt mondta: manapság nagyjából mindenhez hozzá van kötve egy alkalmazás, amely csak tovább járul hozzá az összetettséghez és a zavarhoz, amikor ezeket az információkat fel kell tárolni.
Dez Blanchfield: Igen, láttam már néhányat, a kormányzati oldalak valószínűleg a kedvenceim, de gyakran inkább vállalkozási környezetben látom, ahol van - amint mondtad -, hogy az emberek elfelejtnek még akkor is, amikor telepítenek valamit, például a SharePointot vagy mint például az öncserélés, így tudod, hogy csak beépített ingyenes verzióval érkeznek, mert akarják, tudod, gyorsan telepítik, és nem kell attól tartaniuk, hogy menjenek és licenceket vásároljanak.
Akkor nagysá válik, és akkor valaki panaszkodik a teljesítményről és így szól: „Ez csak a régi szerver, a tároló, a hálózat, bármi is”, majd a DBA felhívásra kerül, és így szól: „Nos, te” mindent beletettem az adatbázis ebbe az ingyenes verziójába, ami nem az, amire szükség van ennek a nagy méretnek a végrehajtásához.
Különösen akkor, ha olyan forgatókönyveket kapsz, mint például a Projektmenedzser és az Office több száz, ha nem több ezer projektet futtat egy nagyvállalaton vagy vállalaton keresztül, és a SharePoint programot a Microsoft Project Server szolgáltatással használják, és az összes PMO-cuccot ebbe az adatbázisba dobják. De a felület elején olyanok, mintha, nos, ez csak egy webes felület. De valóban vannak adatbázisok és adatbázisok.
Bullett Manale: Igen.
Dez Blanchfield: Szóval mik azok, az egyik első lépés, amelyet itt az emberek gondolnak, van néhány kérdés, amelyeket érdemes felhívni a közönség előtt. Az egyik első kérdés az, hogy hol kezdik az emberek? Mi az első természetes lépés számukra: "Oké, meg kell csinálnunk az Alkoholisták Anonim verzióját?"
Több adatbázisunk van, mint tudjuk, mit kell tennünk. Milyen a lépés egyfajta lépésről lépésre: “Oké, meg kell szereznünk ezt a dolgot, és el kell kezdenünk futni?” Csak hideg pulyka mennek, vagy később tényleg kicsinek kell indulniuk, és csak tapasztalatokat szereznek a környezetük feltérképezésében. ?
Bullett Manale: Szerintem ez azt mondta, hogy meg kell térképezni a környezetet. Most a Microsoft egy ingyenes eszközt kínál erre a célra, a Microsoft Assessment Planning Tool-ot, ez egy ingyenes eszköz, de statikus. Ön felfedezi, és ennyi. Kapsz egy listát a dolgokról, amelyek odakint vannak. Vettük ezt, és azt mondtuk, nézzünk egy lépéssel tovább, tegyük fel a felfedezést, nézzük meg, mi van odakint, és tegyük az adattárba, és készítsük úgy, hogy dinamikus legyen, és hozzá tudjuk adni, és eltávolítsuk.
De általánosságban a legnagyobb első lépés az a véleményem, hogy csak kiderül, megteszem a felfedezést. Függetlenül attól, hogy a termékünket próbaverzióban töltse le, akkor letöltheti és kipróbálhatja azt 14 napig, és rámutathat a környezetre, és elkészítheti a gyűjteményt.
Most, ha már van táblázata, amelyben egy csomó információ található, és bizonyos mértékben biztos abban, hogy ezek az adatok helyesek, akkor az a képesség is tetszik, hogy importálja a CSV-be, amely az összes információt tartalmazza a táblázatba, és ennek a részét elkészíti. már megvan. De a kiderítése, amit nem tud, az egyetlen módja ennek manuális kimenet, csinálás vagy eszköz, amely ilyen típusú dolgokat keres, mint ez. Ez az a döntés, amelyet valamikor meg kell tennie: „Megpróbálom automatizálni ezt a felfedezést, vagy legalább jó alapot szerezni az előbbiekhez, majd talán aggódni néhány kivétel miatt?” leginkább valószínűleg szüksége van egy eszközre.
Dez Blanchfield: Szóval csak gyorsan. Hová megy az emberek, hogy kezdjenek ezzel? Megtalálták az Ön weboldalát? Hogyan tudják elérni és hogyan kezdik el gyorsan ezt?
Bullett Manale: Ha elmész az Idera, az IDERA.com webhelyre, akkor látni fogja, és én valójában csak nagyon gyorsan tudom megmutatni azt. Az Idera webhelyén a termékekkel foglalkozik, a készletgazdálkodónál. Itt láthatja a letöltési linket. Csak azt határozza meg, hogy melyik verziót telepíti 64 vagy 32 bitesre, és ez elkészíti Önt, és innen indíthatja a felfedezést.
Robin Bloor: Fantasztikus és nagyszerű, nagyszerű bemutató, nagyon köszönöm.
Bullett Manale: Köszönöm.
Eric Kavanagh: Van néhány kérdés a közönség részéről, és e-mailt küldünk neked, mert ma meg kell keményen megállítanunk magunkat, de Bullett ismét nagyszerű munkát végzett a bemutatóban, nagyszerű munkánk a gyártóval, hogy észrevegye, hogy nem t megmutatja.
Bullett Manale: Sajnálom.
Eric Kavanagh: Nem, ez jó dolog, láthatóságot ad az üzlet magában, igaz? Mivel az üzleti vállalkozás adatokat futtat, és a láthatóságot egészen a magáig biztosítja. Tehát nincs több kézzel hullámos cucc; most tényleg mutathat a dolgokra, és megoldhatja ezeket. Olyan jó neked.
Bullett Manale: Köszönöm.
Robin Bloor: De nagyszerű volt látni, hogy egyébként is élőben van, jól sikerült.
Eric Kavanagh: Igen, archiváljuk ezt a webes sugárzást későbbi megtekintés céljából, és azt remélhetőleg kb. Egy-két órán belül felkészítjük, az eredeti archívum néha felmegy, néha ennél kissé hosszabb is, de biztosan hagyjuk, hogy az emberek tudni. Ezzel elengedjük, emberek. Még egyszer köszönjük, hogy részt vett az eligazító teremben, mi tulajdonképpen a Hot Technologies vagyunk. Legközelebb utolérjük. Vigyázzon, viszlát.
