Elvitel: Eric Kavanagh házigazda az adatbázis-kezelésről és a példány-felfedezésről beszélget Robin Bloor, Dez Blanchfield és Bullett Manale segítségével a Hot Technologies legújabb részében.
Jelenleg nincs bejelentkezve. Kérjük, jelentkezzen be vagy jelentkezzen be a videó megtekintéséhez.
Eric Kavanagh: Rendben 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. Ó, így van, itt az ideje a Hot Technologies-nek. Igen, a nevem ismét Eric Kavanagh. A @eric_kavanagh oldalon találhat meg. Ez az előadás célja, hogy beszéljünk arról, hogy 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 tűnök, 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 forróak. 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ó olvasásakor szörnyű sok mindent hallani fog ezekről - az SQL-adatbázisokról, és a közelmúltban borzasztóan sok zaj van a gráf-adatbázisokról. É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, amelyről ma részletesebben megvitatunk, az Oracle második legnépszerűbb rendszere.
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 meg akarja tenni, de valójában mindkét típusú munkaterhelésre képes. 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 grafikon adatbázis elsősorban az elemzésre szolgál, és a közelmúltban felbukkantak. 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 vállalatnak legalább három van, valójában ez a szám 3,5 volt, 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 kivételes 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ázist igényelnek, vagy valamilyen nagy adatanalitikai célkitűzés után jönnek létre.
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 azt a 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 ez minden bizonnyal a helyzet 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. Hagyja, 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-nál volt, de ha ténylegesen beszéltél velük arról, hogy hány ilyen adatbázist valóban egy DBA figyelt, 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, különböző adatbázisokkal találkoztam, amelyek állítólag ö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ő indexeket helyezi el 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. Mindig ugyanazzal a verzióval foglalkozol. De valójában nagyon sok olyan webhelyen találkoztam, amelyben nem ez történik. 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éses 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 másolatként használják. Ezután a tárolás és a kapacitástervezés, amely a DBA tevékenységének része, mivel természetesen az adatok növekednek, és ezt követni kell. É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, akkor össze kell tekernie a hüvelyé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 ez történt sokkal gyakrabban, mint amire számíthattál volna. A teljesítményfigyelés és a hangolás egyfajta DBA-munka dobogó szíve. Ugyanakkor a biztonság is a hozzáférés kezelése, a biztonsági mentés és a helyreállítás szempontjából olyan szoftver tesztelő rendszereket hoz létre, amelyek ésszerűen párhuzamosak egy élő rendszerrel. És az egész adat életciklusa. Tehát ez véleményem szerint a DBA azon munkahelyeinek listája, amelyektől eltekintve minden, amit felkérhetnek rájuk. 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 ennyi mindent kell mondanom. Átadom Dez-nek.
Dez Blanchfield: Nagyon szépen köszönjük. Kicsit szórakoztató, anekdotikus útra fogok vinni 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élyek é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 nem régen beszéltü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 végez, vannak-e 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ú időbe telt, hogy biztonsági másolatot készítsünk erről a dologról, így nem volt igazán karbantartási ablak, 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 hardverre vá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 középkategóriájú SPARC hardverplatformján az eszközök nem voltak ott, hogy elkezdhessük az adatbázis-környezet diagnosztizálását. 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 számunkra meglehetősen fájdalmas út volt, csak megtettük és megtaláltuk mindent, de most meg kellett diagnosztizálnunk az új termelési rendszeren, és ismét ez a dolog fújt ki egy havi értékű vándorlásból majdnem 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. Számunkra nem volt egyszerű a polcon.
És kihozza ezt az egészet, amikor a működés befejezéséhez és stabilitásunkhoz jutottunk; minden egyes darabja nagyon kézi folyamat volt, és csak valami automatizálható volt, ha ú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, amellyel ma beszélni szeretnénk, az a tény, hogy az eszközök már rendelkezésre állnak, é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 a mai vendégünk, Bullett részéről. Tehát ezzel, Bullett, átadom neked, és várom, hogy meghallgassam, hogyan oldotta meg ezt a problémát.
Bullett Manale: Rendben. 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 fülhallgatót használ, húzza fel kissé.
Bullett Manale: Nem probléma. Jobb ez?
Eric Kavanagh: Sokkal jobb. Elvenni.
Bullett Manale: Rendben. 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 érdekes, hogy soha nem tudtunk erre határozott választ kapni. Nem igazán számított, hogy kivel beszéltél. Mindig ilyen volt: "Nos, azt gondoljuk, hogy körül van ez a szám." Az ilyen jellegű dolgok mindig bekerültek, és akkor ezt a folyamatot át kellett vetnünk, hogy pontosan kitaláljuk, mi az, hogy rendelkeznek azzal, hogy licencünket akarják az általunk kezelt példányok vonatkozásában.
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, a licencszerződésük miatt kell aggódniuk, esetünkben a Microsoft és az SQL Server. Nyilvánvaló, hogy rengeteg más különféle területtel rendelkeznek, amelyekért felelõsek, de ez az egyik, ami egy ilyen nagy jegyjegy, DBA szempontjából, ami 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 társaság 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 ki a felfedező darabot. És emellett képesek legyenek megszervezni és kezelni azt az információt, amelyet összegyűjtünk, olyan logikus módon, amely értelme annak alapján, hogy mi az üzleti tevékenység. É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, ahol az eszköz elindult és honnan származott. Elmondhatom, 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 egy ilyen nagy része is az, hogy tudjuk, hogy ott van.
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épzelheti, hogy DBA-nak elég jó összeget fizetnek azért, hogy fizikailag egyik gépről a másikra sétálhassanak, ami meglepően olyasmi, amit hallanánk néhány olyan nagyvállalattól, amelyeket én még nem neveznék. 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, tegyük meg 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. Így 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 hűvös 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 a példányokat, 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 tenni, vagy ilyen jellegű dolgokat. É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 fő példánya, 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 rendelkezik olyan példányok kiindulási pontjával, amelyekben úgy érzi, hogy magabiztosai vannak, 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. Amint 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 egy fizikai, akár virtuális gép, és különösen a fizikai aljzatok, magok és 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 kihaszná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 eljut 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 kapcsolatban megvan. A termék ilyen 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, alkalmazás-tulajdonosok vagy DBA-tulajdonosok szerint csoportosítja, vagy bármi más, akkor az lehet, hogy hogyan kívánja csoportosítani ezeket a példányokat, hogyan logikusan szeretné értelmezni ezeket a példányokat, akkor ezek kedvesek az eszköz két területének két 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 mindegyik DBA-t feltehetem, aki a felelős az adatbázisért, attól függően, hogy milyen helyzet van, vagy akármi is, attól függetlenül, hogy melyik adatbázisban áll azért felelős szereplők, hogy ezt ki tudja választani, hogy tudjam, hogy ők azok, akik felelősek és nagyon egyszerűen csak a készletbe történő ásás révén.
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, hogy az összes információ összegyűlt, az összes információ és adat, amely a metaadatokat gyűjtötte és alkalmazta, lehetővé teszi számodra, hogy sokkal könnyebb és gyorsabb döntéseket hozhasson, amikor a Microsoft licencét felállítja. a vállalati mennyiségi licencben vagy a szoftverbiztosításban a Microsoftnál.
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, hogy - és annak visszatérése a korábban tárgyalthoz - az SQL Server környezetében 300 példány lehet, de valójában csak egy részhalmaz 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 megszerezte ezeket a 20 példányt vagy a 300 példányt, amelyeket megfigyelünk ezen az eszközön, amelyet arra terveztek, hogy megfigyelje ezt, és megfeleljen a SOA-knak, és figyelmeztetéseket és mindenféle jó dolgot kap ”, amit azt is találtunk, hogy ha megkérdezte:„ Akkor hát mi van ezekkel a többi 280 példánkkal? Érdekel ezekről? ”És ők is törődnek velük, ám 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 tíz vagy 20-as valóban, nagyon kritikus termékpéldányok.
Tehát az egyenlet másik része ezzel az eszközzel az, hogy segít abban is, hogy megbizonyosodjon arról, hogy egy alapszintre vonatkozik-e a példa egészsége szempontjából. Most nem fogja megmondani, hogy van-e patthelyzete, vagy aki a patthelyzet áldozata. Nem szabad eljutni a szekciók szintjére és a lekérdezések részleteire. De ugyanakkor ez továbbra is tudatja Önnel, hogy hé, a szerverek le vannak töltve, vagy hé a kötet megtelik, vagy meg kell készítenie az adatbázis biztonsági másolatát, ez a DBA lényeges része.
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. Lehetséges, hogy magasabb szintű megfigyelést és képes végrehajtani az ilyen dolgokat, míg ezzel képes lesz arra, hogy felvegye a környezethez hozzáadott új példányokat, és ellenőrizze, hogy ezeket figyelembe veszik-e, és ellenőrizze ezeket Az egészségügyi ellenőrzés alapszintjei kialakításban vannak.
Tehát ez egy olyan dióhéjban, amire az Inventory SQL importkezelők szólnak. 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 megmutassam ezt, az SQL példányait, amelyek kezelték, mindent felfedezhetünk az SQL 2000-től egészen az új verziókig SQL.
Tehát meg tudjuk csinálni anélkül, hogy valaha is kellene ügynököket telepíteni magukba a példányokba. Ezt gyűjtőszolgáltatáson keresztül végezzük, és aztán kimegyünk, összegyűjtjük ezeket az információkat, és tárolóba helyezzük, majd a Tomcat webszolgáltatás előlapi konzoljáról képesek leszünk arra, hogy kölcsönhatásba lépjenek az adatokkal és megtekintsék azokat. Tehát a nagyon egyszerű építészet.
Megyek, megyek át, és átváltanak, és valójában elvisznek bennünket magába a termékbe, hogy érezzék magukat és megértsék, hogyan működik. Tehát a legjobb módszer erre az, ha elsőként ismertetjük önmagát a felülettel: ez egy ilyen műszerfal, amelyet itt néztek.
Jelenleg látom, hogy az irányításom alatt álló példányok száma nem olyan sok. De nincs egy teljes adatközpont sem a hátsó zsebemben. Így körülbelül hat példát kaptam, amelyeket itt látunk. Most azt mondtam: Im, amit tennem fogok, ha átjárom a felfedezés folyamatát, és megmutatom, hogyan fog működni.
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 a napi futtatáshoz az adatok gyűjtésére. Szükség esetén ad hoc alapon is meg tudja csinálni. De ha elindítja ezt a felfedezési folyamatot, akkor az látni fogja, amikor átmegy az itt található példánynézetbe. 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 tovább, adjunk hozzá egy példát, amelyet használni fogunk. Tehát ebben az esetben ez egy chicagói eset, igaz? Megyek, és hozzáadom ezt a példányt a leltáromhoz.
Rendben, és átmegyek itt néhány dologon. 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 észreveszi, 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 emlékezni fog arra, hogy legközelebb körül, nyilván.
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álok 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 lenne, ha az SQL szerver vállalati kiadása automatikusan hozzáteszi ezt a készlethez? Nem kell manuálisan mennem, és ezt választanom.
Jocelyn: Megszakítlak téged nagyon gyorsan. Nem láttam a bemutatóját.
Bullett Manale: Te nem?
Jocelyn: Nem.
Bullett Manale: Nos, ez nem jó, láthatjuk.
Eric Kavanagh: Ha a bal felső sarokba lép, kattintson a Start gombra, majd kattintson rá.
Bullett Manale: AH oké.
Eric Kavanagh: És most megoszthatja a képernyőt.
Bullett Manale: Sajnálom. Aha.
Eric Kavanagh: Rendben van. Jó fogás ott, Jocelyn producer.
Bullett Manale: Rendben, így jobb? Most látod?
Robin Bloor: Igen valóban.
Bullett Manale: Rendben, szóval hagyjuk átmenni azon, ahol gyorsan vagyunk. Megtaláltuk a korábban felfedezett példányainkat. Most adtam hozzá a Chicagói példányt, tehát amit most látsz, az itt most szerepel. Vedd észre, hogy már rengeteg további információval rendelkezik. Ha rákattint a maga a példányra, akkor elkezdi látni az összes olyan információt, amelyet már összegyűjtöttünk a példányról. Most itt van az összes, az 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 gyakorisághoz kötnem. A látás alapján lakhatjuk ezt. Most, ha manuálisan szeretne hozzáadni egy alkalmazást, feltétlenül megteheti. De ez csak egy szép módszer arra, hogy megmutassuk a példány társulását az adatbázishoz, vagy, sajnálom, az alkalmazáshoz.
Azt is észreveszi, hogy a képernyő jobb oldalán azonnali összefoglalónk van, alul pedig szerverösszefoglaló. Tehát a példány kulcsfontosságú információiról beszéltünk itt, 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 vannak kötve ehhez 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 betennem - már összegyűjtötték és összegyűjtötték, és ha egyszer megállapítottuk, hogy egy felfedezett példánya, az a készletünk része lesz.
A másik dolog, amit itt látni fog - és meg fogja mutatni neked - a jelen példány nézet alatt. 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á tudunk adni egy nyitott típusú mezőt, és igen / nem tudunk megtenni, tudod, egy milliárdfé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 az összes összegyűjtött és összegyűjtött, és ott van nekünk, mihelyt 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 szempontjából, a logikai és fizikai adatok számát, valamint a memória mennyiségét. Tehát valóban nagyon jó és rengeteg információt szerez be anélkül, hogy sok munkát kellene elvégeznie.
Most a másik rész, amint mondtam, az adatok gyűjtése a szerver szintjén. Ha még az adatbázishoz is megyünk, láthatjuk, hogy ezeknek a dolgoknak a nagy része megoszlik nekünk is.Tehát ha elmegyek a megfelelőség-tárolóhoz, ebben az esetben mondhatnám: jól tudja, hogy ezzel foglalkozik, ez egy megfelelőség-adatbázis, amelyhez a megfelelési szint vagy a szabályozási követelmények társulnak, és lehet, mondjuk, SOX vagy PCI megfelelés. Tehát megválaszthatom, hogy mely adatbázisokhoz kapcsolódik az azokhoz tartozó megfelelés, amelyeket ki kell töltenem, vagy meggyőződhetek arról, hogy ezt a szabályozási követelményt fenntartom.
Tehát ez a fajta cucc nagyon hasznosnak bizonyult a DBA-k számára, mivel itt központilag el lehet jutni ahhoz, hogy az összes kapcsolódó metaadatot könnyen megőrizhessék a környezetükben, és megtehetik, hogy, amint mondtam, megfeleljenek üzleti vállalkozásuknak, ahogy csinálják. , mint üzleti út. Tehát, ha az összes eddig megtekintett dolgot megnézzük, akkor nyilvánvalóan nagyon jó áttekintést kapott a példányról, ha belemegyek.
Keresni is tudok, tehát azt mondtam, hogy a megfelelőségi tárolót keressük meg 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, hogy 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 azt a bontást, ahol látunk bármit, amelyben megfeleltek, és be tudom mélyíteni, é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ód van a metaadatok létrehozására a példánykiszolgálón és az adatbázisban. 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 annak alapja a tulajdonos, aki birtokolja azokat a példányokat, amelyek ott vannak, talán 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 festesse 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 azt és a kollégáink számára, vagy megtehessünk mindent, amire szükségünk van. Tehát tudod, hogy képes leszel ilyen dolgokat megtenni. Visszatérhetünk - elvesztettem? Oda megyünk. Rendben, remélhetőleg ez értelme annak, amit Ive eddig beszélt. Most, hogy az adatokat, amelyeket összegyűjtöttünk, 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 állíthatja be a riasztást, és meg tudja győződni arról, hogy azoknál a dolgoknál, amelyekről valóban tudni szeretne, beállíthatja ezeket a dolgokat. Tehát beállíthatunk riasztásokat, beállíthatjuk az egyes dolgok bekapcsolásának és bizonyos dolgok kikapcsolásának képességét, majd meghatározhatjuk, ki fogja kapni ezeket az üzeneteket, és feliratkozva ezekre a riasztásokra társíthatjuk azokat, akiket szeretnénk legyen, aki tudni akarja az ilyen fajta dolgokat.
De amint már korábban mondtam, ez egy nagyon szép módszer, legalábbis teljes nyugalmat biztosítva, ha az egész vállalati SQL példányokat megismeri - mi van, és ügyeljen arra is, hogy az optimálisan működjön, még akkor sem, még nem döntöttek arról, hogy befektetnek-e egy erőteljes teljesítmény-figyelő eszközre, amely az adott példány kezelésére szolgál. 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 megmutatta neked. Azt hiszem, ebből a szempontból továbbléphetek, és tovább beszélhetnénk.
Eric Kavanagh: Ez jól hangzik. Tehát Robin? Dez? Bármi kérdés?
Robin Bloor: Nos, vannak kérdéseim. Nagyon érdekes ezt valóban nézni, úgy értem, csak azt akartam megtenni, hogy mindenhol ott 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, mindegyikük táblázatok kidolgozása.
Eric Kavanagh: Úgy van.
Dez Blanchfield: Valahogy tudod, hogy ez, te is tudod, hogy 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 érdekel, és tudom, hogy neked nehéz megválaszolni, de mi van, ha olyan helyre megy, ahol a táblázatok működtetésére nincs ilyen ilyesmi, akkor tegyük fel a DBA-kat nagyon okos srácok és így tovább, és így tovább, Ön szerint milyen beruházási megtérülést érhet el valami hasonló végrehajtásával? Van számod erről, vagy bármilyen iránymutatás?
Bullett Manale: Nehéz megmondani, mi az a ROI, mivel a környezet kissé eltérő 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 Ive sokkal - amikor mondom a nagy szervezetek ezreit és ezer alkalmazottat és valószínűleg a több ezer példányt is - beszéltünk olyan emberekkel, ahol ezt mutatom meg nekik, és azt mondják, hogy két hétbe telik. az én időm vissza. Ive ezt már egyszer mondta nekem. Tehát nehéz megmondani a vásárlás tényleges dollárösszege szempontjából, de számottevõ, ha a környezetben van.
Mint mondtam, nagyon következetes, az emberek, akikkel vagyok, és a legtöbb ember, akivel beszélek, ezeket a dolgokat táblázatokban tartom. Tehát ez csak egy nagyon, nagyon szubjektív dolog, mivel minden környezet, egy kicsit különbözik attól, hogy hogyan hajtják végre az engedélyezést és hogyan hajtják végre a Microsoft általi engedélyezést, ez egy másik tényező. De ha évente vagy háromévente igaz dolgot kell tenniük, azt hiszem, hogy a Microsoft számára legfeljebb három évvel ez tényleg megtörténik, azt akarják, hogy legalább háromévente igazítson.
Akkor tudod, hogy számottevõ, és tudja, 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, úgy értem, SQL licenc, ennek licencbe adása csak egy átkozott rémálom, de különösen rémálom, mert a licenc nem azonos a Microsoft és az Oracle között, és bárki más is végez adatbázis-tevékenységeket. Ha valójában a táblázatokon tartja a dolgokat, ami általában az történik, akkor tudja, hogy az engedélyezési idő körül megy, mielőtt ténylegesen megvalósul, és valójában nincs olyan adata, ha tudja, hogy mire gondolok, hogy könnyen megszerezze ezt az információt.
Mindenesetre, amint rámutatott, annak dinamikája és személyes fogalmam sincs róla, mert az Ive-nek valójában soha nem kellett tárgyalnia a Microsoft-tal, így fogalmam sem volt, de feltehetően léteznek olyan adatbázisok, amelyekben az emberek elég gyakran levonják a teszteredményeket, a tesztelési környezeteket, és én Gondolj arra, hogy ezek egy tövis az ön oldalán, ha licenckezelést végeznek. Te vagy az-?
Bullett Manale: Igen, igen. Ez a helyzet azért, mert sokszor elfelejtik ezeket a dolgokat, és akkor elkezdjük kitalálni, oké, jól van, jó licencet kaptunk, hogy ki kell számolnunk az egyes példányok magjainak számát, és nem tudom, a hardver bölcs vásárlására vonatkozó szabványok szempontjából valószínűleg nagyon jó hardvert is vásárolhat, ha ha nem ezt a hardvert használja úgy, ahogyan azt ki kellene használni, akkor túlfizet, mert fizetsz a központi árazásért, amikor ezeket a magokat nem használják fel úgy, hogy problémává válik.
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émi kihívása ennek körül, és ezért 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 magunk 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 nekem eszembe jut, ó, sajnálom ...
Robin Bloor: Rendben, menj Dezbe, egy esetlegesen irreleváns kérdést akartam feltenni.
Dez Blanchfield: Csak valami nagyon gyorsan, amíg a témája jelenleg aktuális - sokkal inkább felhős környezeteket fogadtak el, és ha ezt a saját adatközpontunkban, a saját környezetünkben futtatják, viszonylag egyszerűen másznak és megtalálnak, felfedezhetnek dolgokat. .
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 egy cső vagy VPN végén található adatkészletről van szó. Van-e felfedezés a felületről, vagy kell-e megkezdenie a portok megnyitását, hogy bizonyos környezetekben átvizsgálhassuk 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 az, sajnos azt szeretném mondani, hogy áttör minden ilyen környezetet, de van néhány különféle lehetőség, amelyeket ezzel megtehetsz. Nyilvánvaló, hogy ha valami hasonlót csinál, mint például az Amazon EC2, akkor valóban szükséged van a környezethez való hozzáférésre a kapcsolaton keresztül, ha feltételezzük, hogy a portok nyitva vannak, és meg tudja adni az ehhez társított IP-címeket vagy domainjét, és elindulhat a gyűjtemény és kezdje meg a felfedezést.
Tehát az, az ilyen típusú környezetekben ez valójában nem jelent problémát; a környezet specifikusabb típusai, mint 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, ott vannak az adatbázisok és az 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 megosztottam az elején, ahol csak egy hatalmas platformja van, és csak az, hogy adatbázist biztosítson. Manapság az adatbázisok mindenbe be vannak ágyazva, sőt, olyan, mint kettő vagy három, csak a telefonomban futó alkalmazások mögött.
Milyen kihívásokkal szembesül olyan forgatókönyvek, amelyekben a Lotus Notes alkalmazásból származó környezeteket kaptak, alkalmazásokat mögöttük, a SharePointot a különféle internetes adatbázisokkal stb.? 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, azt értem, hogy az a helyzet, hogy amit mondtál - mindennek most adatbázisra van szüksége, tehát sokszor valószínűleg nagyon sok olyan adatbázis van, amely bekerül a környezetbe, és amelyet a DBA maguk sem készítenek. tisztában van azzal, hogy á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. Annyira vicces, hogy amikor ismét beszélgetsz a DBA-kkal, akkor nem kapnak következetes választ azzal kapcsolatban, hogy érdekli-e őket a szabad adatbázisok, amelyek ott vannak. Ezen alkalmazások közül sok, amelyekről beszélt, az adatbázis ingyenes verzióját fogják használni. De maguk a szervezetek másképpen fognak attitűdön állni, hogy ki felelős az adatbázisért, attól függően, hogy kivel beszélgetnek.
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égük részét képezik 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 a lakosok másik fele: „Hé, nem voltak felelősek az adatbázisokért, és bármi, amit rájuk raktak, vigyázni kell az embertre, aki telepítette őket.” De azt mondanám, hogy összességében, amit mondtál, minden nagyon szép Manapság sok olyan alkalmazás van hozzákapcsolva, 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 néhányat, a kormányzati webhelyek valószínűleg a kedvenceim, de gyakran nem látom a vállalati környezetet, ahol - amint mondtad - az emberek elfelejtenek még akkor is, amikor valami hasonlót telepítenek SharePointhoz vagy öncseréhez, mint tudod hogy éppen beépített ingyenes verzióval érkeznek, mert tudják, gyorsan telepítik, és nem aggódnak azért, mert licencvásárlást kell vásárolniuk.
Akkor nagysá válik, és akkor valaki panaszkodik a teljesítményről, és azt mondja: „Csak a régi szerver, a tároló, a hálózat, bármi is”, majd felhívják a DBA-t, és így vannak: „Nos, te csak mindent beillesztett 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-tartalmát ebbe az adatbázisba dobják. De a felsõ részükre tetszik, és ez csak egy webes felület. De valójában ezek az adatbázisok és adatbázisok.
Bullett Manale: Igen.
Dez Blanchfield: Tehát mi ezek, az egyik első lépés, amelyet itt az emberek gondolnak, hogy 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ük: "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: Nos, azt hiszem, azt mondta, hogy meg kell térképezniük a környezetet. Most a Microsoft egy ingyenes eszközt kínál erre a célra, a Microsoft Assessment Planning Tool-t, egy ingyenes eszközt, de statikus. Ön felfedezi, és az is. Kapsz egy listát a dolgokról, amelyek odakint vannak. Vettük ezt, és azt mondtuk, hogy a pillantás egy lépéssel tovább járulhat hozzá a felfedezéshez, megkeresheti a dolgok odakintjét, teheti a lerakatba, és lehetővé teszi, 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 van egy csomó ilyen információ, és benne vagy benne, hogy bizonyos, hogy az információ helyes, akkor az a képessége is, hogy tetszik az importálás a CSV-be, amely az összes információt tartalmazza a táblázatkezelővel, és az Ön részét képezi már megvan. De a kitalálás szempontjából, 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. Az a döntés, amelyet valamikor meg kell hoznia, az a következő: „Megpróbálom automatizálni ezt a felfedezést, vagy legalábbis jó alapot szerezhetek az ottani dolgokhoz, majd talán aggódnék néhány kivétel miatt?” De a legtöbb Önnek valószínűleg szüksége van egy eszközre.
Dez Blanchfield: Tehát 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 az Idera-ra, az I-D-E-R-A.com-ra megy, látni fogja, és valójában csak gyorsan tudom megmutatni. Az Idera weboldalon keresztül meglátogathatja a termékeket, majd a raktárkezelőt. Itt láthatja a letöltési linket. Csak azt határozza meg, hogy melyik verziót telepíti 64 vagy 32 bitesre, és ezzel megkezdi a munkát, é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ünk a közönség részéről, és önnek is vannak, mert ma nehéz megállítanunk magunkat, de Bullett ismét nagyszerű munkát végzett a bemutatóban, nagyszerű munkánk a gyártónkkal, ami azt mutatta, hogy nem jelenik meg.
Bullett Manale: Sajnálom.
Eric Kavanagh: Nem, ez jó dolog, láthatóságot ad az üzleti tevékenység magában, igaz? Mivel az üzleti vállalkozás adatokat futtat, és a láthatóságot egészen a magáig nyújtja. 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: Nagyon jó volt látni, hogy egyébként is él, jól sikerült.
Eric Kavanagh: Igen, archiváljuk ezt a webes sugárzást későbbi megtekintés céljából, majd remélhetőleg kb. Egy-két órán belül felkészítjük az eredeti archívumra, néha kissé hosszabb lesz, ám biztos, hogy mindenképp tudassa velünk. Ezzel elengedték, emberek. Még egyszer köszönöm, hogy részt vett az eligazító teremben, valójában a Hot Technologies volt. Jöjjön hozzá legközelebb. Vigyázzon, viszlát.