Huis databases De droom van de dba: ontdekking en beheer in de omgeving

De droom van de dba: ontdekking en beheer in de omgeving

Anonim

Door Techopedia Staff, 22 februari 2017

Afhaalmaaltijd: gastheer Eric Kavanagh bespreekt databasebeheer met Dr. Robin Bloor, Dez Blanchfield en Binh Chau van IDERA.

Je bent momenteel niet ingelogd. Log in of meld je aan om de video te bekijken.

Eric Kavanagh: Oké, dames en heren. Hallo en welkom weer. Het is een woensdag, het is vier uur Eastern Time en de laatste jaren betekent dit dat het tijd is voor Hot Technologies. Dat klopt, dit is onze show met onze vrienden Techopedia - Techopedia.com. Bekijk ze online. Ze krijgen monsterverkeer, 1, 5 miljoen unieke bezoekers per maand. Dat is veel webverkeer. Het onderwerp vandaag, "De DBA's Dream: Discovery and Management Across the Environment." Ja, inderdaad, het is een groot probleem, vooral voor grotere organisaties. Er is echt een dia over die van jou, en genoeg over mij, sla me op Twitter @eric_kavanagh, ik probeer altijd terug te volgen en in gesprek te gaan daar.

Nogmaals, we hebben het vandaag over databasetechnologieën en we kunnen echt begrijpen wat er gaande is in een breed landschap van database-instances. Zoals velen van jullie weten, als je eenmaal begint met het uitbreiden van je organisatie, krijg je veel meer van deze instanties en is het een beetje een interessante uitdaging om daar grip op te houden. Ik herinner me zelfs een aantal jaren geleden dat ik een goed gesprek had met een man die directeur gegevensbeheer was voor het kantoor van de CIO op het ministerie van Defensie. En ik vertelde hem al deze interessante dingen, we hadden dit geweldige gesprek en ik vertelde hem mijn achtergrondverhaal over lobbyen voor transparantie in de federale uitgaven, en hij lachte en hij zei: "Oh, dus het is jouw huis waar ik dat naar toe moet sturen roofdier drone staking. "Hij zei:" Transparantie in federale uitgaven? Ik weet niet eens hoeveel Oracle-licenties ik hier heb. ”Toen ik dat hoorde, kon ik de omvang van de uitdaging waar sommige organisaties voor staan ​​echt waarderen.

Nu zijn er tegenwoordig veel interessante tools - we horen er vandaag één over - om te begrijpen wat er rondvliegt, maar zelfs 20 jaar geleden was dat een heel serieuze uitdaging. Als het gaat om organisaties met de grootte van DOD, kun je je gewoon voorstellen dat het krijgen van een handvat dat veel geld gaat besparen, het veel tijd zal besparen, het gaat enkele bestuurlijke problemen oplossen; als je dit soort dingen correct doet, moet je meerdere uitdagingen tegelijk oplossen. Daar zullen we vandaag over leren.

We hebben onze eigen Dr. Robin Bloor, hoofdanalist van The Bloor Group. We hebben Dez Blanchfield, onze datawetenschapper, vanuit Down Under, Sydney, Australië. En Binh Chau, senior productmanager van IDERA, is ook aan de lijn.

We doen #HOTTECH als de hashtag - voel je vrij om weg te tweeten tijdens de show. En we vertrouwen op jullie voor goede vragen, dus wees niet verlegen: stel vragen op elk gewenst moment met behulp van de Q & A-component van je webcastconsole of dat chatvenster, hoe dan ook. En daarmee ga ik het overhandigen aan Dr. Robin Bloor. Laat me hem de sleutels van de WebEx overhandigen. Daar gaat het en neem het weg.

Dr. Robin Bloor: Oké. Nou, hier gaan we, laten we verder gaan naar de eerste dia. In Italië noemen ze hen Stanlio en Olio, Laurel en Hardy. In de jaren 90, toen iedereen zich zorgen maakte over het jaar 2000, raakte ik betrokken bij een aantal projecten van het jaar 2000. En ik ging naar - laten we ze een grote verzekeringsmaatschappij noemen - en ze ontdekten dat ze meer dan 500 applicaties hadden waarvan ze niet wisten dat ze op het mainframe bestonden. Ze maakten een inventaris van het mainframe. Nou, in die dagen werden mainframe-omgevingen veel beter verzorgd dan alles dat later kwam, ik bedoel, er is gewoon geen twijfel over mogelijk.

Ik was echt een beetje verbijsterd en ik sprak met mensen in de organisatie en ze zeiden dat er geen centrale was, er was geen persoon die verantwoordelijk was voor het kennen van die informatie, weet je, eigenlijk. Ze hebben nooit inventaris van hun vermogen gemaakt. En een database is een troef, niet in onzekere bewoordingen omdat deze gegevens en waardevolle gegevens bevat. Hoeveel instanties is de vraag en waar zijn ze eigenlijk? Dit is gewoon "Wat is een database?" En de reden waarom ik zo denk, een database is een kast waarin je gegevens gooit. En ik sprak onlangs met een site die duizenden instanties van Oracle had. Nou, Oracle is een database die, als je hem op een geavanceerde manier gebruikt, een DBA vereist.

Ik heb daar een beetje naar gevraagd en ze zeiden dat ze, denk ik, ongeveer zeven of acht DBA's in de hele organisatie hebben. En ik zei, weet je, "Wie zorgt er voor de andere duizenden instanties?" En ze zeiden: "Wel, echt wat er is gebeurd is dat mensen het gewoon als een bestandssysteem gebruiken. We hebben een aantal databases die zich in grote clusters bevinden waar prestaties echt belangrijk zijn en ze hebben DBA's die er altijd overheen staan. En dan hebben we duizenden andere databases waar helemaal niemand voor zorgt. "En ik vroeg hen precies hoeveel databases en ze kwamen met:" Wel, de laatste keer dat Oracle het controleerde. "Ze deden zelf geen audits, weet je, wat best interessant is.

Maar weet je, er zijn redenen om een ​​database te gebruiken. Een database implementeert een datamodel. Het is er voor het delen van gegevens: kan meerdere gelijktijdige verzoeken om gegevens beheren, een beveiligingsmodel implementeren, voldoet aan ACID, is veerkrachtig of kan worden ingesteld om veerkrachtig te zijn, weet u. Dat is de reden dat we databases hebben. Maar weet u, het is niet ongebruikelijk om sites met duizenden exemplaren van SQL Server of Oracle tegen te komen en de meeste daarvan worden in principe alleen als bestandssysteem gebruikt. En dus waarom zou je echt een nieuwe instantie maken?

Ik weet van ontwikkelteams dat als ze een nieuwe applicatie bouwen, ze deze in een silo bouwen, zodat elke nieuwe applicatie een aparte database zou hebben. Ze zouden niet noodzakelijkerwijs proberen om een ​​gegevenslaag van dingen te maken - ik denk niet dat dat een goede praktijk is. Maar nogmaals, weet u, als u een zeer gecompliceerde omgeving hebt, wordt het heel, heel moeilijk om te proberen alle databases die aan elkaar gerelateerd zijn samen te stellen in termen van gegevens in zich waar er relaties zijn. Instanties worden gemaakt voor replica's.

Weet je, je kunt hot standbys of replica's gebruiken voor beschikbaarheidsdoeleinden, maar je hebt ook replica's of semi-replica's in datamarts. En zodra de wereld van het datawarehouse werd geïntroduceerd, de vraag, weet je, hoeveel datamarts waren er, en mensen gebruikten ze gewoon als kloonbestanden, haalden data uit het datawarehouse en waren niet bijzonder geïnteresseerd in de prestaties in de het gevoel dat ze het gewoon zouden doen als standaardprestaties. De meeste van deze mensen wisten waarschijnlijk niet eens dat je databases kon afstemmen. Ik heb ontwerpen gezien die gegevens in onderscheidende hopen hebben weggegooid met het oog op distributie.

Weet je, je krijgt vaak deze replicatiesituatie waarbij je meerdere depots binnen een organisatie hebt en ze hebben elk databases en elk is een scherf van een centrale database. Je krijgt exemplaren van scherf. Slechte ontwerpbeslissingen - Ik heb een aantal echt bizarre ontwerpen zien plaatsvinden in termen van databases waar mensen zonder goede reden afzonderlijke databases hebben gemaakt. En zoals ik heb opgemerkt, zijn databases bestandssystemen.

En dan zijn er nog de test- en ontwikkelomgevingen die rechtop moeten staan ​​en vallen, maar ze tellen allemaal als databasevoorbeelden en ze hebben trouwens allemaal beveiliging nodig en alle andere dingen die de database hopelijk biedt. Exemplaaroverwegingen - een database-werkbelasting kan alleen worden geoptimaliseerd voor een specifiek exemplaar. Als u echt geïnteresseerd bent in absoluut de beste prestaties, dan is het niet noodzakelijk dat u dat soort optimalisatie krijgt als u gegevens in veel databases weggooit.

Er is een reden om geen onechte gegevensexemplaren te maken. Gemengde werkbelastingen op dezelfde database als het contrapunt kunnen leiden tot slechte prestaties - vooral opmerkelijk door OLTP en groot queryverkeer worden niet gemengd, nooit gemengd en zullen waarschijnlijk nooit mengen. Het is meestal het beste om een ​​database op serverniveau te consolideren in plaats van meerdere VM's te hebben. Maar VM's bieden isolatie; bij sommige mensen is het een ontwerpbeslissing om gegevens van andere gegevens te isoleren, zodat, weet je, als die applicatie faalt, of als die database faalt, het mijn applicatie niet naar beneden haalt.

Het probleem daarmee is natuurlijk dat je het volgende punt tegenkomt, dat zijn licentiekosten voor de database. Die variëren, maar ik heb gezien dat databaselicentiekosten een ontwerpcriterium werden omdat iemand een bepaald aantal niet wilde laten barsten, en daarom mensen die systemen slecht ontwerpen simpelweg vanwege de manier waarop de databaselicentie werkt. En er is nog iets: als u al uw databases begint te consolideren, is het vermeldenswaard dat DBA's duur zijn. Dat is niet zo gemakkelijk om te doen.

Een eenvoudig beeld van de wereld - en dit is eigenlijk de laatste dia - er is een gegevenslaag, er is een transportlaag en er is een verwerkingslaag. En alle hardware zit daaronder. Het is niet echt mogelijk om de gegevenslaag te optimaliseren zonder precies te weten wat erin zit en waarom.

En dat gezegd hebbende, zal ik doorgeven aan mijn vriend van beneden naar beneden, Dez Blanchfield.

Dez Blanchfield: Bedankt, Robin. Laat me mijn muis hier uitzoeken. Dus ik ga ons vandaag een paar anekdotes geven omdat dit een enorm onderwerp is en ik twee weken kon doorbrengen met een whiteboard-marker die er plezier aan had, omdat ik bijna drie decennia op en neer in deze ruimte heb gehad .

Maar eerst een mentaal visueel beeld. Als ik denk aan de uitdaging waar we het vandaag over hebben - en in wezen hebben we het over databasegroei, replicatie en wildgroei en alle uitdagingen die daarbij horen - wilde ik deze foto van een gigantische eik gewoon in onze geest. Dit zijn beroemd mooie bomen, ze beginnen als een kleine eikel maar ze groeien naar deze kolossen. En als ze dat doen, zijn ze erg groot en rommelig. En zoals je aan dit beeld kunt zien, als een visuele metafoor, als je wilt, weet je, overal gaan takken en dan komen takjes eraf en bladeren aan het einde daarvan en ze zijn in alle willekeurige, chaotische vormen, en dat is net het stukje dat we boven de grond kunnen zien.

Ik zie dat soort gegevens als gegevens in de database, en daaronder is er een structuur van wortels en ze tappen in allerlei richtingen. Maar het lijkt erg schoon en verstandig aan het oppervlak van de grond daar waar het mooi vlak is, maar de realiteit is dat het net zo gek onder de grond is als boven de grond; we zien het gewoon niet. En ik gebruik dit vaak als ik begin na te denken over het beschrijven van de uitdaging waar we vandaag over praten aan organisaties van de directiekamer tot aan de techneuten om hen te laten visualiseren wat er feitelijk in hun organisaties gebeurt. Omdat het zo eenvoudig is om naar een computerscherm te kijken en deze prachtige velden met rijen en kolommen te zien en te denken: "We hebben het opgelost, het maakt niet uit." Maar dat is helemaal niet het geval. En dus het is op dat moment dat ik meestal op die ene regel druk en zeg dat databases in mijn gedachten als eikels zijn, weet je, ze beginnen klein en groeien, maar voor je het weet heb je een bos met gigantische eikenbomen, en daarom het visuele.

Dus, twee anekdotes om een ​​scenario te delen dat uit de hand liep en gewoon niet kon worden opgelost, en nog een die hetzelfde deed maar kon worden opgelost, en ik zal het kernpunt van de discussie van vandaag benadrukken over hoe we zijn erover gekomen.

De eerste was een scenario waarin een CIO met de grootste bedoelingen in de loop van de tijd onbewust een van de meest onverwachte en ongewenste wildgroei veroorzaakte die gewoon onbeheerst groeide. Het was een scenario waarin een overheidsorganisatie met duizenden medewerkers, zeer technisch onderlegde medewerkers, toegang eiste tot haar systemen en tools waarmee ze konden beginnen samen te werken en veel van hun processen konden automatiseren. Ze wilden weg van papieren formulieren en ze wilden online systemen maken, ze wilden gegevens vastleggen en volgen en monitoren en rapporteren en teruggeven aan hun collega's.

En er zijn allerlei dingen, er zijn dingen van mensen die naar hun kantoor komen en inchecken en inloggen voor veiligheidsdoeleinden helemaal tot wie wat bestelde in de cafetaria tijdens de lunch. En dus besloot een goedbedoelde CIO dat Lotus Notes een geweldig idee was, omdat hij naar een reeks seminars was geweest en IBM het uitstekend had gedaan om het te pitchen en in het juiste scenario zou het een geweldige beslissing zijn geweest, het is onder controle gedaan. Maar wat er gebeurde, was in plaats van Lotus Notes overhandigen aan een team van technische mensen om een ​​soort in een omgeving te implementeren en vervolgens verstandige tools op te zetten, enzovoort en enige controle en governance eromheen te bieden, wat er feitelijk gebeurde, werd het geïmplementeerd volgens de standaard besturingsomgeving, SOE, dus elke desktop werd effectief een server.

En dus zorgden ze voor training en praktische notities en documentatie voor dit hele proces en realiseerden de mensen zich plotseling: "Ja, ik heb Lotus Notes op mijn bureaublad!" Wat betekent dit, denk je? Welnu, het betekende dat duizenden zeer technisch onderlegde medewerkers werden geleerd hoe ze apps kunnen schrijven en schrijven, in Lotus Notes effectief, kleine databases maken die in wezen eruit zagen als spreadsheets, rijen en kolommen en velden, en deze kleine webinterface presenteren via Domino.

Als ik informatie over iets wilde vastleggen, kon ik gewoon een klein formulier en in een spreadsheet-achtige interface maken, het in een bestand plaatsen, er een kleine Lotus Notes-database achter maken en het presenteren als een web-app en beginnen met het verzamelen van informatie. En dat klonk geweldig totdat het jarenlang had gedraaid en plotseling realiseerde ze zich dat iemand wakker werd en zei: "Wacht even, waarom verschijnen er 10.000 nieuwe database-gestuurde apps op het LAN, en met name in de laatste 12 maanden? Wat is er aan de hand? 'Wat er gebeurde, was dat je mensen in wezen een pistool gaf, en het was geladen en de veiligheid was uitgeschakeld, en natuurlijk schoten ze zichzelf in de voet.

En er is hier een geweldig beeld dat ik meestal opdoe in mijn gedachten van een Italiaanse kunstenaar die dit rare ding doet, waar hij een vrachtwagen vol hooi en stro krijgt en midden in een kunststudio wordt gedumpt en vervolgens een curator van de kunststudio krijgt om een ​​naald er willekeurig in te steken. En dan besteedt hij dagen aan live feed, op camera, door het rietje zoekend naar de naald in de hooiberg, als het ware. Tot hij het uiteindelijk, na uren en dagen, vindt en op en neer springt en opgewonden raakt. En hoe dan ook, Italiaanse kunstenaar, wat kun je doen? Maar het is vrij humoristisch en als je het ooit online hebt bekeken of als je het online bekijkt, vind je het erg cathartisch.

Hier is een nachtmerriescenario waarin een goedbedoelde technische persoon zakenmensen - zeer technisch onderlegde zakenmensen - een hulpmiddel gaf dat hun leven gemakkelijker moest maken. Maar het duurde niet lang voordat we vragen hadden over wie er een back-up van maakt, wie ze bewaakt en ondersteunt, waar deze gegevens zijn, in welke structuur de gegevens zitten, wie de schema's controleert, wat als ik een andere versie wil maken, welke gegevens in die versies zitten, kan ik een dev-testintegratiereis op deze dingen maken?

Weet je, je kunt je eigen conclusies trekken over hoe het ging, maar het ging niet goed en je kunt je voorstellen dat slechts honderden terabytes aan gegevens, en geen back-up, effectief, pc's of laptops op bureaus, sommige systemen niet eens beschikbaar zijn omdat mensen niet wisten wanneer ze de laptop om 5.30 uur uitschakelden en mee naar huis namen om werk te doen dat niemand op het LAN bij die applicatie kon krijgen. Het is niet goed afgelopen. En veel gegevens moesten worden opgeruimd en handmatig worden gemanipuleerd en teruggebracht in een verstandig systeem; het grootste deel werd gewoon weggevaagd en verwijderd, omdat het gewoon niet meer toegestaan ​​was zich verder te verspreiden.

Dan mijn tweede anekdote met dingen op een heel andere reis. Stel je een scenario voor, je hebt dev, test, integraties, systeemintegraties, testen van gebruikersacceptatie, productie, noodherstel, back-ups en back-up één tot 99 en verder, je hebt upgrades, patches en demonstratieomgevingen van één tot en met 99 en meer. En ineens zit je daar en zegt: "Wacht, wat is er aan de hand, wacht even, wie gebruikt wat?" Weet je, dit is een nachtmerrie die mogelijk staat te gebeuren.

Maar in dit scenario was wat er gebeurde, ik de kans kreeg om naar een organisatie te gaan die een bedrijf voor vermogensbeheer uit hun kernbankplatform wilde halen en het wilde verdedigen als een afzonderlijke organisatie in wezen een startup binnen een onderneming. De uitdaging was om onze vermogensbeheerafdeling en alle mensen en technologie en gegevens eromheen bij de openbare diensten te nemen, een startup in ons eigen bedrijf op te zetten en af ​​te hakken zodat het op zijn eigen merk kan draaien.

Dit is een wereldleider in bankieren, die ik niet zal noemen. We moesten de business unit voor vermogensbeheer zelf en alle dingen eromheen extraheren. Dus alles in zijn geheel, al het personeel, de fysieke infrastructuur, en het verplaatsen naar een nieuwe kantoorruimte. Alle bedrijfssystemen, alle software, alle gegevens, alle licenties, noem maar op. Nou, je kunt je voorstellen, dat leek een beetje een nachtmerrie om mee te beginnen.

En om het wat context te geven, hebben we het over 78 systemen in het oorspronkelijke bankplatform dat ongeveer 14 kernproducten ondersteunt, wat ongeveer duizend verschillende aanbiedingen kan zijn. Honderden en honderden live databases in gebruik, en wanneer ik in gebruik zeg, moesten we ze in situ verplaatsen, dus op een vrijdagmiddag zouden ze in één omgeving zijn, op maandag wordt verwacht dat ze ergens anders zijn en op zaterdag en zondag moesten ze deze cross-over hebben waar transacties van het ene systeem aan de linkerkant gingen, laten we zeggen, om het te visualiseren, naar een ander systeem aan de rechterkant.

Ongeveer 15.000 klanten met talloze records elk, en een ETL-nachtmerrie omdat geen van de 78 systemen aan de ene kant werden geëvenaard door systemen aan de andere kant. We hadden een volledig nieuw bankplatform, nieuwe systemen, nieuwe software, nieuwe databases en een nieuw schema. Dus, metadata, velden, rijen, kolommen, records, tabellen, noem maar op, er is niets aan de hand. Er zijn 14 verschillende actieve ontwikkelingsteams, één voor elk product. En toen we deze omgeving bouwden, merkten we dat tegen de tijd dat we een ontwikkelingstest, integratie, systeemintegratie, testen van gebruikersacceptatie, productie, noodherstel, demonstratie-kopieën, back-ups, upgrades, patching hadden - ik heb er zelfs een gemist - training bijvoorbeeld en onderwijs, er waren 23 versies van elk van deze omgevingen voor elk ontwikkelingsteam.

Nu zit je daar en opeens begint je bloed te stremmen en wordt je huid koud en staat je haar - dat kan nooit goed eindigen. Nou, het bleek, het eindigde heel goed, want het allereerste wat we deden, voordat we zelfs begonnen met het ontwerp van de technologie-implementatie, was dat we gingen en de juiste tools kregen. En we gebruikten gereedschappen, en niet noodzakelijkerwijs mensen, maar mensen die gereedschappen besturen. We hebben tools gebruikt om de gegevens in kaart te brengen, we hebben tools gebruikt om de databases waarin ze leefden in kaart te brengen, we hebben alle metagegevens, de schema's en helemaal tot rijen, kolommen, records en velden in kaart gebracht.

We wisten waar we vandaan kwamen en dat correleerden we met de kaart van wat we aan het opzetten waren voor zover het kant-en-klare bankplatform eruit zag, en we hadden een één-op-één correlatie. En alles wat in het midden viel, we creëerden een dataroom waar we doorheen zouden gaan en ze handmatig in kaart zouden brengen. Maar voordat we deze omgevingen in de nieuwe wereld implementeerden en opzetten, zorgden we ervoor dat elk record, elke tabel, elk veld, elke rij, elke kolom, elke database en alle metagegevens eromheen, alle machtigingen en besturingselementen werden toegewezen, van één tot één. En we hebben niets verplaatst totdat die correlatie was gemaakt.

En dus ging het ETL-stuk van een nachtmerrie naar een vrij pijnloos proces van alleen het valideren van de controles en processen die werden gevolgd. En we kunnen dit op regelmatige basis doen, bijna elk uur. We waren bezig met de overgang van productie op de oude wereld naar nieuwe omgevingen van ontwikkelaar, test, integratie, enz., In de nieuwe wereld. En op de dag dat we live gingen, na een proces van vijf maanden om na een maand live te gaan met het testen en vervolgens in zes maanden online en actief was, hadden we maar één probleem, en het probleem was dat iemand zijn wachtwoord was vergeten en het moest opnieuw worden ingesteld. Dat was het enige probleem dat was ontstaan ​​en in wezen ongeveer een uur van stress veroorzaakte bij mensen die dachten dat er iets mis was gegaan - het bleek dat een wachtwoord was verlopen en ze vergaten wat het was en moesten het opnieuw instellen.

Je kunt je dat scenario voorstellen, vergeleken met de Lotus Notes-omgeving waar iemand grote bedoelingen had maar de uitdaging niet had overwogen, en het volgende wat we moesten gaan proberen al deze gegevens in kaart te brengen en het grootste deel ervan moest worden afgeschreven en het was gewoon een groot verlies van tijd en moeite en middelen en moreel. Naar een scenario waarin, wanneer het goed gepland en correct gedaan en op de juiste manier geleverd is met de juiste tools, we een geweldig resultaat hebben.

En dat punt brengt me bij deze ene regel - voordat ik het aan onze medewerker overhandig om te praten over wat IDERA deze zeer uitdaging moet oplossen - is dat het in de wereld van vandaag waar systemen in toenemende mate worden aangedreven door databases, niet alleen een aardigheid is, maar voor mij is het een feit, het is een noodzaak, dat slimme tools naar mijn ervaring de enige manier zijn om gegevensontdekking, gegevensbeheer in de schaal en de snelheid waarmee we bewegen te beheren.

En als het goed wordt gedaan, als de tweede anekdote die ik hopelijk net heb geïllustreerd, kan het een zeer pijnloos en zeer naadloos proces zijn. Niet alleen in nieuwe projecten, maar ook om je armen rond een huidige omgeving te houden en ervoor te zorgen dat je op elk moment en elke dag kunt volgen en traceren wat er in je organisatie gebeurt, welke database er is, welke versies van de database je gebruikt en wie wat gebruikt.

En daartoe zal ik het aan onze medewerker van IDERA overhandigen en ik kijk er naar uit om te horen wat ze te bieden hebben op tafel en hoe ze deze uitdaging zullen oplossen.

Binh Chau: Geweldig, bedankt, Dez. Kunnen jullie me goed horen? Oke, bedankt. Hallo allemaal, ik ben Binh Chau met IDERA. Vandaag ga ik een beetje praten over producten die we SQL Inventory Manager hebben genoemd en het gaat over de ontdekking en de mogelijkheid om uw SQL Server-exemplaren en -databases daar te inventariseren en een greep te krijgen op wat u hebt in de omgeving en praten over enkele andere dingen waar Dez en Robin het over hadden over de verspreiding van databases en de behoefte aan gegevens tegenwoordig.

Daarmee is hier een overweging die je, volgens mij, anekdotisch hebt gehoord door de twee verhalen die Dez aan het beschrijven was. Maar eigenlijk is er tegenwoordig zoveel behoefte aan gegevens en bedrijfsgroepen en bedrijfsgroepen die hun eigen applicaties en servers draaien, met name met SQL Server, toch? Omdat je eenvoudig een SQL Express-versie of BI-services kunt laten draaien, is er bij veel organisaties gewoon SQL-uitbreiding, weet je, van de kleine tot de grote.

Vaak weten DBA's niet dat iemand heeft besloten een instantie te starten in plaats van een database op een bestaande instantie te plaatsen. Ze zijn zich niet bewust van deze dingen totdat er mogelijk een probleem is en iemand de DBA belt: "Oh nee, mijn applicatie werkt niet meer, het kan geen verbinding maken met een database, wat is er aan de hand?" En weet je, wanneer de DBA vraagt sommige vragen ontdekken ze: "Hé, deze stond niet op onze radar, we wisten het niet."

Een andere zijn licentiekosten, toch? Microsoft SQL Server-licentie: de manier waarop het werkt, is dat u geen specifieke sleutel hoeft te hebben voor dat aantal instanties dat u hebt. Je kunt inzetten en dan doen ze een audit. Weet je, ze doen later een audit en ontdekken een beetje hoeveel licenties je eigenlijk nodig hebt. En dus, als ze een audit uitvoeren en u zich niet bewust bent van de onbekende servers, kan dit leiden tot een soort dure audit. Daarom is het een goede zaak om de tool te hebben of vooraf een inventaris te hebben om te weten wat uw licentiekosten zijn en om het niet alleen te kennen maar ook te beheren.

En dan, waar ik het zojuist over had, als je je niet vaak bewust bent van een server, als alles goed verloopt, is alles goed, maar de enige keer dat je ergens bewust van wordt is wanneer er een probleem is. En dus kan dat leiden tot productieonderbrekingen of misschien werd de server niet onderhouden en kreeg je geen patch op die server en dat levert een probleem op.

Sommige van de vragen die een DBA soort van dag tot dag moet doen, is dat ze geconfronteerd worden met, ze kunnen administratief of strategisch zijn, maar sommige dingen zoals, Microsoft heeft zojuist een kritieke systeempatch uitgebracht, hoeveel systemen daar nodig hebben deze nieuwe patch? Op wie is downtime van invloed als ik het systeem moet uitschakelen om het te repareren? Hoe kan ik die informatie gemakkelijk bereiken? Moet ik in een spreadsheet gaan? Moet ik meerdere systemen ingaan om dat te vinden? Moet ik contact opnemen met de verschillende bedrijfsgroepen om die lijst te krijgen? Het is echt moeilijk om het te splitsen.

Een andere goede is eigenlijk, er komt iemand langs en ze zeggen: ik heb een nieuwe database nodig. Het vereist X-formaat en het moet zoveel capaciteit hebben, en dan willen ze weten, waar kan ik het plaatsen. Zonder te weten wat er in je landschap is, is het moeilijk om ze te vertellen, oké, we kunnen het hier, hier of hier plaatsen. Je moet je handmatige controles uitvoeren om dat voor elkaar te krijgen. En we hadden het over de auditing, en ook over de malafide server.

Als u een malafide server hebt, weet u niet in welke staat deze zich bevindt, of er een back-up van is gemaakt, of alle patches aanwezig zijn. Soms word je je pas bewust van die dingen als er een probleem is, wat slecht zou zijn.

Dat zijn soort van alle uitdagingen, de vragen, de DBA die dagelijks worden geconfronteerd, wat hen wordt gegooid. Daarom wilde ik de SQL Inventory Manager aan je voorstellen, een product dat we daar hebben. Het doet een paar dingen. Het doet ontdekking, wat eigenlijk een soort van uitgaan is naar uw omgeving om te zien wat SQL Server daar in uw omgeving is. En dan kan het ook automatisch ontdekken, dus in principe, als je eenmaal een ontdekking hebt uitgevoerd, kun je deze instellen om dagelijks of wekelijks naar buiten te gaan - op welk tijdstip je ook wilt - om nieuwe exemplaren te ontdekken die er zijn.

En dan kunt u deze exemplaren ook automatisch laten registreren, zodat u ze kunt gaan controleren en hun gezondheidstoestand kunt controleren en vervolgens kunt u die exemplaren gaan catalogiseren en inventariseren, zodat u een goed zicht hebt op uw SQL Server-landschap. Wat is er, wat is productie, wat is ontwikkeling, wat is noodherstel, wat is minder kritisch en weet je, welke applicaties er op draaien. En u kunt ook meldingen ontvangen voor wanneer dingen, wanneer de gezondheidscontrole mislukt, dus in principe als de server uitvalt of voor een aantal extra dingen die u zelf kunt gebruiken.

Eric Kavanagh: Je wordt een beetje zacht, gewoon zodat je het weet.

Binh Chau: Sorry, is dit beter? Wat ik wil doen was jullie door een demo nemen, jullie laten zien wat het doet. Wacht even, laat me eerst mijn scherm delen. Zien jullie de webinterface? Dit is de SQL Inventory Manager-interface. Het scherm dat ik je hier laat zien, het is een webgebaseerde interface. Het scherm dat ik u hier laat zien, is onze database-instance-weergave. Bovenaan zie je dat we anders zijn. "Ontdekt" is dus in feite alle instanties die het op het netwerk heeft ontdekt. En wat het me gaat laten zien is eigenlijk.

Eric Kavanagh: Je begint daar een klein beetje uit elkaar te gaan. Misschien wilt u de telefoon neerleggen en op de luidspreker zetten. Doe Maar.

Binh Chau: dit Discovery-scherm toont je alles wat de Inventory Manager op je netwerk heeft ontdekt. Hier wordt het ontdekt als 1.003 servers die er zijn. En het vertelt u de versie, de editie, of het het kan vinden, wanneer het werd ontdekt en hoe het werd ontdekt. Laten we zeggen dat ik er bijvoorbeeld voor kies om enkele van deze te negeren, wat betekent, weet je, misschien wil ik de Developer Edition negeren omdat ze niet zo belangrijk voor me zijn omdat ze slechts Developer Edition zijn; Ik kan ervoor kiezen om deze te negeren en het zal ze op het tabblad Negeren plaatsen, dus de volgende keer dat ik Discovery start, wordt het me niet meer getoond. Nu kan ik invullen om automatisch te registreren of kan ik me handmatig registreren.

En dus heb ik ervoor gekozen om zes instanties te controleren. En hier is het ingelogd en het gaat hier periodieke controles op uitvoeren en dan zijn er meerdere controles, alles hier, weet je, het controleert elke 30 seconden om te zien of de server omhoog of omlaag is en het geeft je een soort overzicht van wat die staat is. In feite vertelt het me dat ik één server heb die down is en deze vijf die up zijn. Het vertelt me ​​ook welke serveredities, het aantal databases, de status van de databases, eventuele aanvullende inventaris of metadata rond die server. Vanaf hier kan ik ook naar de licentieweergave gaan. Hier geeft het me een deel van de Microsoft-licentie-informatie die ik nodig heb als ik een totaaloverzicht of een samenvatting voor een Microsoft-audit wil krijgen.

Hier is het aantal cores, het aantal sockets, de mogelijke kernlicentie, iets dat Microsoft vanaf 2012 heeft geïntroduceerd. Dat was ons standpunt. Onze overzichtspagina, dit is een soort pagina die je opent. Dit zal je de gezondheidscontroles of aanbevelingen laten zien die het heeft, zoals nu het me vertelt dat ik negen databases heb die geen huidige back-up hebben. Ik kan daar klikken om naar de details te gaan van welke databases dat zijn en ik kan naar binnen gaan en daar actie op ondernemen als dat nodig is. Het vertelt me ​​alle topdatabases op grootte, topdatabases op activiteit. Ik kan in de betreffende server klikken en er meer informatie over krijgen.

Eric Kavanagh: Terwijl dat aan het rollen is, wat je ons hier laat zien, is de mogelijkheid om echt alles te zien dat verbonden is met het netwerk, klopt dat?

Binh Chau: Juist. Dit toont alles wat ik heb gekozen om te controleren met behulp van Inventory Manager. Dit is een SQL Server, het laat me hier alle applicaties zien die verbonden zijn met de server. Nogmaals, ik kan alle databases ophalen die op deze server zijn gekoppeld. Hier zou ik dingen kunnen taggen. Ik kan een tag maken voor deze specifieke server, ongeacht of het een nauwkeurig domein is. We hebben klanten die het gebruiken, bijvoorbeeld omdat ze hun productieservers of hun schuldenervers willen taggen en dan kunnen ze een soort volledig overzicht krijgen van hoe dingen zijn. Terwijl ik naar het tabblad Beheer ga, kan ik op deze manier Discovery uitvoeren. En Discovery gaat in principe je netwerk binnenlopen en alle SQL Server in je omgeving vinden.

Hier heb ik dit Precieze domein dat een domein van ons is en ik heb het ingesteld om te zeggen, weet je, op dit specifieke domein gebruik dit specifieke Windows-gebruikersaccount om ontdekking te doen en ik wil dat je een volledige scan uitvoert. Ik kan er ook voor kiezen om "Alleen dit specifieke subdomein scannen" of "Alleen de ouder scannen" te selecteren. Maar in dit geval heb ik gezegd: voer de volledige scan uit. Hier zijn de verschillende scantypes die ik kan gebruiken en als ik die opsla, en eigenlijk is het een taak die ik kan instellen. Op dit moment is het uitgeschakeld, wat betekent dat ik deze scans handmatig zou moeten uitvoeren. Maar als ik zou willen, zou ik het dagelijks kunnen instellen, weet je, de taak dagelijks uitvoeren. Of als ik ervoor kies om het niet dagelijks uit te voeren - het is teveel - kan ik zeggen dat ik de taak wekelijks op een specifieke datum en tijd moet uitvoeren.

En dan is automatische registratie hier, als dit is ingeschakeld, wat het zou doen, is dat het elke keer dat het een nieuwe server vond, het automatisch in Inventory Manager gaat registreren, zodat ik het kan gaan controleren. Als er een soort editie is die ik wil uitsluiten, zoals bijvoorbeeld, ik geef niet om de Express- of Developer-editie omdat dit een ontwikkelomgeving is, dan zou ik hier gewoon op klikken en wat het zal doen is dat er gewoon elke keer dat ik iets nieuws vind, voeg ik het gewoon toe aan Inventory Manager zodat je het kunt volgen zolang het geen Developer- of Express-editie is.

En hier kan ik de tags instellen, dus als ik bijvoorbeeld productieservers heb, zou ik hier naartoe kunnen gaan om die servers te taggen. Ik zou een database of server kunnen taggen met een specifieke blauwe tag, dus ik zou bijvoorbeeld kunnen zeggen dat deze AO_NODE een productietag moet hebben. En als ik op deze manier gemakkelijk bij de server moest komen, kan ik hier naar buiten gaan en op de productietag klikken en dan ga ik meteen naar die twee servers. Dit is onze Explorer-weergave en dit wordt getoond door de Eigenaar, maar ik zou kunnen zeggen door de Instance-tag, ook door databases en ik kan dit uitbreiden om te zien wat ze zijn.

Een andere handige functie die we hebben gebouwd die mensen hier echt leuk vinden, is de mogelijkheid om te kijken naar wat je beheert via Inventory Manager en te zien op welk patchniveau ze zich bevinden. Kort gezegd, hier vertelt het me hier de zes servers die ik in mijn tools heb beheerd, of er al dan niet een update beschikbaar is voor Microsoft en of de versie die ik gebruik, of deze wel of niet wordt ondersteund, en de ondersteuning toestand. Als ik meer wil weten over deze specifieke hotfix, kan ik erop klikken en het zal me linken naar het artikel van Microsoft over waar die hotfix over gaat en of deze moet worden aangepakt. Je kunt deze lijst exporteren als je dat wilt, zodat je op die manier kunt zeggen: "Hé, ik moet misschien drie van deze servers dit weekend patchen en de andere drie op een later tijdstip."

De Build-lijst - er is dus een lijst waarmee wordt gecontroleerd of uw versie up-to-date is. Je kunt deze lijst downloaden en downloaden om er zeker van te zijn dat deze up-to-date is en dat je de nieuwste lijst hebt om mee te vergelijken. Een andere handige inventarisfunctie die mensen leuk vinden, is de mogelijkheid om niet alleen tags toe te voegen, maar ook de mogelijkheid om aangepaste inventarisvelden toe te voegen. Weet je, als je hier een veld wilt toevoegen om bijvoorbeeld een database te taggen, laten we zeggen dat ik het op databaseniveau wil taggen. Afdeling, deze afdeling en deze database, ik zou er een ander type van kunnen maken: open-einde, waar / onwaar of keuzelijst.

En ik zou kunnen zeggen, weet je, dit is een HR, marketing, R&D, financiën. En wat dit hier doet, is eigenlijk, als je deze dingen eenmaal kunt taggen, kun je hier wat gegevens uithalen die aangeven hoeveel capaciteit elke database gebruikt en dan kun je beginnen, groeit het en is het zinvol om deze afdelingen terugbetalen?

Een ander ding is, weet je, als je onderhoud moet uitvoeren, door te weten wie er in die database zit, kun je weten met wie je contact moet opnemen om hen te laten weten: "Hé, ik moet dit weekend onderhoud uitvoeren, je databases zijn offline, " enzovoort. Een andere handige functie is het zoekvak dat mensen hier leuk vinden. Vaak worden DBA's gevraagd naar een database of een applicatie of een server, afhankelijk van wie met hen praat, is het moeilijk om erachter te komen waar dat precies is. Wat je hier zou kunnen doen, is dat je misschien niet weet waar de database woont, maar je zou het gewoon kunnen typen. Ik zou gewoon het IDERA Dashboard kunnen typen en het zal een paar databases openen en waar ze zitten, zodat je gemakkelijk kunt krijgen aan diegenen. En dan haalt het aanvullende informatie over hen op: hun grootte, een loggrootte, of het ooit een back-up heeft gehad, in welke herstelmodus het zich bevindt, als ik er tags aan wil toevoegen. Er zijn veel verschillende functies in deze tool, weet u, het is een inventarisatietool maar het is een inventarisatietool die zeer specifiek is voor SQL Server en voor DBA's.

Omdat er, denk ik, extra dingen zijn waar de DBA graag toegang toe wil hebben of een goed beeld wil krijgen van hoe de omgeving en hun landschap eruit zien voor hun databases. U kunt zich ook abonneren, de SMTP-server configureren en een abonnement instellen om te waarschuwen voor uzelf of voor gebruikers hier. Ik ga dit stoppen en teruggaan naar de presentatie. En deze laatste dia hier is slechts een eenvoudige weergave van de architectuur. Het is een webconsole die wordt uitgevoerd op een ingesloten Tomcat Web Services.

We hebben een aantal incassoservices en beheerservices die we in een repository plaatsen en de beheerservices worden uitgevoerd en Discovery wordt uitgevoerd op uw verschillende SQL Server-exemplaren. Er is niets op uw monitorservers geïnstalleerd. We hebben taken die periodiek worden uitgevoerd en er alleen gegevens over verzamelen, dus in principe of het omhoog of omlaag is, hoeveel gegevens worden gebruikt, wat de andere versies van mensen zijn. Nou dat is alles.

Eric Kavanagh: Ja, laat me je vragen - ik zal een paar vragen stellen en dan weet ik zeker dat Robin en Dez er ook een paar hebben - gewoon uit nieuwsgierigheid, wanneer iemand binnenkomt om een ​​audit te doen, laten we zeggen Microsoft, zijn gebruiken ze deze tool, of ik neem aan dat ze een aantal eigen tools hebben die ze gebruiken?

Binh Chau: Ja, ik geloof dat ze eigen tools gebruiken. Het ding is dat dit hulpmiddel een inventarisatieprogramma is, dus het blijft up-to-date in termen van, weet je, omdat het de taak heeft om uit te gaan en continu informatie over je servers te verzamelen, het zal daar op elk gewenst moment opraken je hebt up-to-date informatie, in feite over hoe dingen veranderen versus, je weet wel, eenmalige rapporten die je van Microsoft kunt krijgen om te zeggen dat dit het aantal servers is dat je hebt, dit zijn de versies die je hebt .

Eric Kavanagh: Ja, ik ben nieuwsgierig naar Discovery. Dus wanneer iemand deze tool koopt en begint te gebruiken, hoe gebeurt de ontdekking eigenlijk? Dit was een soort van waar ik eerder op doelde, met andere woorden, ben je op het netwerk aan het tikken om te zien welke signalen daar vliegen die database-instanties lijken te zijn en dan catalogiseer je dat en als je eenmaal een database-instantie hebt getagd die je houdt toezicht? Ik gok dat het een soort ping heeft die het om de zoveel tijd doet en als het uitvalt, weet je bijvoorbeeld dat het uitvalt. Is dat hoe de dingen werken?

Binh Chau: Ja. Ik bedoel, zodra je Discovery hebt ingeschakeld, gaat het naar je netwerk en we hebben verschillende scans om daar naartoe te gaan, maar het doet, weet je, een browserscan en registerscan. Er worden verschillende scans uitgevoerd om te kijken welke computer er is en vervolgens wordt gecontroleerd: heb je SQL Servers of BI-services die er zijn? En dan brengt het het terug en trekt het in de tool en laat het je zien: "Hé, hier zijn alle dingen die ik heb ontdekt."

En als je dan zou zeggen: "Ik wil monitoren met behulp van deze tool", dan houdt het dat bij en gaat het pingen. Het heeft taken om het zo nu en dan te pingen om te zeggen: "Oké, controleer dit nu eens", weet je, de beschikbaarheid van de database - controleer het nu over de databasegeschiedenis, controleer de databasekant. Het voert een reeks taken uit om de database te controleren die u bijhoudt.

Eric Kavanagh: Ja, dat is goed. En we hebben een vraag van een lid van het publiek. Ik weet dat jullie tools hebben die werken met een verscheidenheid aan databasetechnologieën, maar deze wordt met name vandaag getoond, is dit alleen voor SQL Server of heeft dit ook betrekking op andere databasetypen?

Binh Chau: Op dit moment dekt deze specifieke tool SQL Server.

Eric Kavanagh: Oké, dat is prima. Nou, laat me het aan Robin overdragen, ik weet zeker dat hij een paar vragen heeft, en dan misschien terug aan Dez. Robin?

Dr. Robin Bloor: Ja, zeker. Microsoft heeft vrij recent - ergens in 2006 - SQL Server op Linux aangekondigd, maar ik denk niet dat het het al heeft opgeleverd. Ik vroeg me af of je daar opmerkingen over hebt. Ben je je daarvan bewust? Speel je daarmee?

Binh Chau: Ja, dat zijn we. We zijn van plan dat op te nemen. Ik bedoel, het leuke van deze tool is dat ik met veel klanten heb gesproken die hun eigen zelfgemaakte tools hebben gebouwd om hetzelfde te doen, maar ze moeten gelijke tred houden met de nieuwe edities en versies die Microsoft komt met, maar we hebben nieuwe versies en edities, we komen er vroeg op in om ervoor te zorgen dat de tool de nieuwe edities soort kan controleren en beheren. Dus SQL op Linux is iets dat we van plan zijn toe te voegen en beschikbaar te maken wanneer het beschikbaar is - ik geloof later dit jaar.

Dr. Robin Bloor: Ja, dat is interessant. Verwacht u dat veel van uw klanten dat ook daadwerkelijk doen? Ik bedoel, SQL Server is een zeer geavanceerde database, in mijn ervaring. Ik bedoel, weet je, het zit lang in de tand, het is waarschijnlijk het ding om te zeggen. Ik bedoel, weet je, de oorspronkelijke Sybase waar hij vandaan kwam, was eigenlijk vrij simplistisch in veel dingen die hij deed. Maar Microsoft heeft in de loop der jaren steeds meer dingen toegevoegd. Zal dat allemaal beschikbaar zijn op Linux? Ik bedoel, gaat u uw klanten adviseren over het maken van die migratie?

Binh Chau: Het spijt me, is de vraag dat we mensen daarnaar vragen?

Dr. Robin Bloor: Nou, gezien het feit dat je ermee hebt geknoeid, is het net zo geavanceerd op Linux als op Windows?

Binh Chau: Ik heb er zelf niet mee gespeeld, maar wat ik van een collega heb gehoord, is dat het eigenlijk erg op één lijn ligt. Maar ik heb persoonlijk niet gespeeld met de nieuwe versie van SQL op Linux.

Dr. Robin Bloor: Oké. Heb ik gelijk als ik denk dat je eenvoudig agenten op elke SQL Server hebt geplaatst die je tegenkomt? Is dat hoe deze tool werkt?

Binh Chau: Nee, we plaatsen eigenlijk geen agenten. Voor dit specifieke hulpmiddel, het stuk Voorraad, zetten we daar eigenlijk geen agenten op. We gaan gewoon een beetje uit en bellen en controleren de statussen erop. Een leuk ding aan deze tool is dat het agentloos is.

Dr. Robin Bloor: Dus je hebt andere SQL Server-tools, kun je me eraan herinneren wat voor andere producten je in deze suite hebt die te maken hebben met SQL Server?

Binh Chau: Ja. We hebben SQL Diagnostic Manager. Het is een monitoring- en performance-tool. Het voert meer diepgaande analyses of diagnostische en prestatie- en gezondheidscontroles voor u uit dan Inventory Manager. Inventory Manager is de lichtgewicht versie van die health check. We hebben ook Compliance Manager en Secure, dat deel uitmaakt van onze beveiligingssuite. Het zal u in principe vertellen wie toegang heeft tot uw gegevens, tot welke gegevens ze toegang hebben, waarom, en het helpt u met compliance en andere rapportagerichtlijnen. We hebben SQL Safe, wat ons back-uptool is - het doet back-up en herstel en dat is een leuke.

We hebben ook onze Enterprise Job Manager, die alleen uw taak controleert. En dan hebben we de Toolbox-tool, beheerders-toolsets en ook Comparison-toolsets, evenals SQL Doctor. Admin toolset en Comparison toolset, ze zijn wat ik zie als een Zwitsers zakmes. Ze hebben meerdere tools om de DBA te helpen verschillende dingen te doen, zoals, je weet wel, patches controleren of een database verplaatsen of klonen. Maar er zijn 24 dergelijke tools in die Toolbox.

Dr. Robin Bloor: Dus, zijn de mensen die voor Inventory Management gaan, zijn ze normaal gesproken al gebruikers van uw andere tools? Of is dit een toegangspunt? Ik kan het me voorstellen - ik bedoel, je kunt me vertellen of je oorlogsverhalen hebt - maar ik kan me voorstellen dat als je nog nooit een inventaris hebt uitgevoerd in een redelijk groot datacenter, de ervaring behoorlijk ontnuchterend kan zijn. Is dat wat je vindt?

Binh Chau: Ja. Ik bedoel, we hebben klanten die kennis hebben gemaakt met de tool van andere toolsets, maar we hebben klanten die op zoek zijn naar een tool zoals deze vanwege projecten die ze hebben. Een voorbeeld was dat er een bedrijf was dat fuseerde met een ander bedrijf en een reeks bedrijven kocht en hun SQL Server-voetafdruk moest consolideren om hun kosten te verlagen. En dus waren ze op zoek naar een tool om een ​​beetje uit te gaan en alles te ontdekken wat ze hadden, zodat ze kunnen beginnen met het proces van hoe we dit kunnen consolideren.

Dr. Robin Bloor: Juist, ik begrijp het. Ik denk dat dat vrij gebruikelijk is bij fusies als je erover nadenkt. Oké, ik zal Dez doorgeven, ik wil niet de hele tijd nemen. Kijk welke vragen we hebben uit Australië.

Dez Blanchfield: Bedankt, ja, de vragen staan ​​hier altijd ondersteboven. Een van de dingen die in me opkomt, en ik begrijp dit best veel, weet u, bedrijven weten niet precies waar ze de grens moeten trekken om te beginnen met investeren. Wanneer moet een organisatie - volgens uw ervaring gezien het feit dat u zich in de koude fase bevindt - wanneer het juiste moment is om te beginnen met het investeren in dergelijke tools om ervoor te zorgen dat u niet in de problemen komt? Doe je het vanaf de eerste dag wanneer je begint met het bouwen van je database-infrastructuur van de nieuwe organisatie of, zoals je zojuist hebt geschetst, wanneer je een acquisitie / fusie doet?

Of is er een bepaalde schaal waarop u echt moet zijn? Heeft u 10 of 100 of 1.000 databases nodig? Wat is je ervaring tot nu toe met de markt waar je al zo lang mee te maken hebt, wanneer is het juiste moment om in deze ruimte te komen en waarschijnlijk, waar te beginnen? Hoe ziet het eruit als je aan de slag gaat?

Binh Chau: Ik bedoel, ik denk dat als het een heel kleine organisatie is, je misschien geen behoefte hebt aan deze tool, zoals met een DBA of een paar DBA's. Wanneer je een groep van, ik weet het niet, drie of vier DBA's en misschien 50 tot 100 servers begint te krijgen, wil je misschien zoiets beginnen. Ik neem aan dat, naarmate je organisatie groter wordt en alleen zakenmensen die technisch onderlegd zijn willen, weet je, net als dat voorbeeld dat je gaf, ze de applicaties en databases zelf willen installeren, maar dat is wanneer je dit soort tool, omdat je op die manier kunt zien wat er is.

Maar zelfs in een kleinere organisatie is het leuk om dit type tool te hebben om bij te houden wat je hebt. Als je het opsplitst zodat je kunt zeggen: "Oh ja, ik heb SQL 2012 voor dit vak gekocht, maar het draait momenteel SQL 2008 omdat ik een toepassing heb die nog steeds die oude versie nodig heeft." om zo min mogelijk meerdere spreadsheets te beheren die oud kunnen worden.

Dez Blanchfield: De andere vraag die ik zojuist heb gesteld: welke soorten vaardigheden of middelen moeten organisaties van plan zijn te hebben als ze die schaal bereiken? Is het het geval dat er een bepaalde vaardigheden zijn die je echt nodig hebt of een soort ervaring of achtergrond of het type persoon dat het meest geschikt is voor dit soort uitdagingen? Of is het iets waar de gemiddelde vaardigheden van het type DBA of sys admin of netwerkbeheerder dit naar toe kunnen gooien? Heb je echt een scherp puntig brein nodig of kun je dit vrij snel oppakken?

Binh Chau: Sorry, dus je had het over de vaardigheden van de persoon?

Dez Blanchfield: Ja, dus als je denkt aan een databasebeheerder, zijn er bepaalde vaardigheden die je nodig hebt. Dus als je per se een DBA gaat inhuren voor die specifieke rol, als je nadenkt over de soorten uitdagingen waar je het hier over had, waarbij je een tool als deze gebruikt om het in kaart brengen en bijhouden van databases bij te houden, het doen van het ontdekkingsstuk en het besturen van deze specifieke tool, is er iets unieks aan het gebruik van de tool en de aanpak van dit soort uitdagingen, of is het iets dat de gemiddelde DBA vrij snel kan oppakken?

Binh Chau: Ik bedoel, ik denk dat je gemiddelde DBA dit snel kan oppakken. Ik denk dat het nuttig is om dit type tool te hebben, omdat je het ook kunt omdraaien omdat het webgebaseerd is. U kunt het aan andere gebruikers binnen uw organisatie geven. Je zou het kunnen geven aan de app-ontwikkelaar die zijn specifieke database of server kan controleren. Het neemt enkele administratieve zaken weg die een DBA moet doen. Vroeger belde iemand de DBA en zei: "Oh, waarom is mijn server omhoog of omlaag?" Nu kunnen ze een beetje toegang krijgen en zien of hun servers omhoog of omlaag zijn.

Dez Blanchfield: En wat voor soort omgeving zou een gemiddelde organisatie nodig hebben om dit in te zetten? Heeft het een speciale fysieke server nodig of kan dit op een virtuele machine? Kunnen ze het in de cloudomgeving implementeren? Wat is de algemene voetafdruk voor de implementatie van de tool en alleen de algemene werking ervan? Hoeveel zwaar ijzer moet het mogelijk parallel laten lopen met de andere omgevingen die het in kaart brengt?

Binh Chau: Ja, het kan worden uitgevoerd op een VM of een computer of een server. Het hoeft niet per se een dedicated server te zijn, het hangt er maar vanaf hoeveel servers je in de gaten houdt. Als u een grotere omgeving hebt, kan het helpen om een ​​grotere server te hebben, omdat deze veel gegevens verzamelt over de SQL Server die u bewaakt.

Dez Blanchfield: Rechts. Is het iets dat je comfortabel in de cloud kunt uitvoeren en een VPN terug naar je omgeving kunt creëren, of is de hoeveelheid gegevens die het verzamelt waarschijnlijk een beetje zwaar voor dat soort gebruik?

Binh Chau: We hebben het nog niet ingesteld om het op de cloud te laten draaien, om dit nog in de cloud te laten draaien. Het zou waarschijnlijk op prem moeten draaien.

Dez Blanchfield: En de laatste vraag, als ik kan: veel van de tools die ik in deze ruimte heb gezien, vooral waar je het noemde voor een scenario waarin iemand een bedrijf overnam of een fusie of zoiets, of zelfs als het een organisatie was die alleen bedrijfsonderdelen samenvoegt, is het dan een verstandig use case-scenario waarbij iemand het op een laptop implementeert en het naar een omgeving brengt om een ​​wereld als eenmalig in kaart te brengen, of is dat een onwaarschijnlijk use case-scenario? Is het meer het geval dat het daar zal zijn en gewoon permanent moet worden uitgevoerd?

Binh Chau: Deze specifieke tool is meer een soort installatie op een server en blijft daar staan ​​om te draaien. Op die manier kun je de informatie verzamelen die je daarvoor nodig hebt en, denk ik, een lopende inventaris bijhouden van wat je hebt. Het is anders dan de kaarttool omdat de kaarttool een beetje een-op-een is, ga naar de poort die je nodig hebt, doe wat je er vandaag mee moet doen. Deze is een beetje - het leuke eraan is dat je het een beetje kunt taggen, mensen toegang kunt geven om de status van hun specifieke server, degene waarin ze geïnteresseerd zijn, te controleren.

Dez Blanchfield: Oké. Waarschijnlijk de laatste vraag voor mij en dan zal ik teruggeven aan Eric voor vragen die via het Q & A-venster met de aanwezigen binnenkomen, omdat we vandaag een goede opkomst hebben gehad, een van mijn favorieten. Om dit af te ronden, wat is het proces om dit in handen te krijgen? Ik weet dat veel van je tools beschikbaar zijn voor dingen die je kunt proberen voordat je iets koopt. Waar moeten mensen naartoe gaan om meer hierover online te leren, waar ze op de website moeten zoeken naar de downloads en hoe ziet de reis eruit, doen ze een soort proof of concept of een proef en krijgen het in handen en raken ermee vertrouwd dan contact opnemen en kopen?

Binh Chau: Ja. U kunt naar de IDERA.com-website gaan en u kunt een proefperiode van twee weken gratis downloaden. En als je het leuk vindt en je wilt contact met ons opnemen, kunnen we ook een demo plannen met een van onze technici om een ​​beetje dieper in de tool te duiken.

Dez Blanchfield: Fantastisch. Wel, heel erg bedankt daarvoor. Ik waardeer de tijd om erover met je te praten en op basis van mijn persoonlijke ervaring en ik weet zeker dat ik hier tijdens zijn levenslange ervaring over Robin spreek, denk ik dat het een gegeven is dat zoiets tegenwoordig een vereiste is. We kunnen dit nu niet handmatig doen, hoe hard we ook proberen; de schaal is gewoon te groot en dingen gaan te snel.

Ik raad mensen ten zeerste aan om precies dat te doen, op de IDERA-website te springen en een exemplaar te krijgen om mee te spelen. Omdat het potentiële risico voor mijn eigen ervaring met de anekdotes die ik net vandaag heb gedeeld, is geweest dat het snel van heel slecht naar heel goed kan gaan, als je de juiste tools hebt, maar het kan ook de andere kant op gaan als je ' t. Eric, terug naar jou.

Eric Kavanagh: Ja, kom maar even langs voor een laatste vraag aan jou, een interessante. Ik ben gewoon een beetje nieuwsgierig om te weten wat je daar ziet, weet je, de cloud is tegenwoordig natuurlijk steeds belangrijker - Amazon Web Services, maar ze zijn niet de enige, Microsoft heeft het hele Azure-aanbod dat lijkt stoom te winnen. Ik ben nieuwsgierig om te weten, een van de aanwezigen schrijft dat Dr. Bloor een interessant punt maakte dat DBA's duur zijn en dat managementproblemen worden veroorzaakt door ofwel een malafide DBA of iemand die niet doet wat hij zou moeten doen, kan dat worden opgelost door te migreren naar de cloud. Ik ben echt gewoon nieuwsgierig om te weten, hoeveel activiteit zie je? Zie je dat migratie naar de cloud een steeds groter probleem wordt voor bedrijven, of wat vind je daarvan als een trend?

Binh Chau: Ik heb het gevoel dat het gewoon afhangt van wat voor probleem je bent. Ik heb het gevoel dat sommige industrieën zeggen: "Nee, we migreren niet." Ze migreren misschien niet naar een openbare cloud; ze kijken misschien naar migratie of migreren hun spullen naar een private cloud. Maar dan zie ik een aantal organisaties die geïnteresseerd zijn in, weet je, echt op het goede spoor komen en een beetje op weg gaan naar een Amazon of Microsoft Azure. En dan zijn er mensen die zeggen: "Nee, we migreren onze gegevens niet" of "Er zijn alleen bepaalde gegevens die we zouden migreren, maar niet onze kritieke gegevens." Ik denk dat er drie soorten kampen zijn.

Eric Kavanagh: Ja, dat zou logisch zijn. Ik bedoel, we zien dat steeds meer en ik denk dat het geruime tijd past en begint te bewegen. En er is ook een terugslag naar de cloud. Mensen stappen in Amazon Web Services - we hebben dit meer dan een paar keer gehoord - en in het begin zijn de kosten beheersbaar en na verloop van tijd kruipt het gewoon omhoog en dan zit je er een beetje vast. In veel opzichten is de cloud gewoon een ander datacenter, maar het zal op zijn zachtst gezegd een interessante reis worden.

Nou, mensen archiveren al deze webcasts. Spring online naar techopedia.com om een ​​complete lijst te bekijken van alle dingen die we doen. En natuurlijk, insideanalysis.com voor het laatste nieuws. En daarmee gaan we u vaarwel zeggen. En nogmaals heel erg bedankt voor je tijd en aandacht. Bedankt voor al onze vrienden bij IDERA en we spreken je morgen hopelijk voor onze filosofie van gegevens met als hoogtepunt webcast. Dat klopt, Philosophy of Data is morgen om vier uur Eastern. Ik hoop je daar te zien. Pas op mensen, tot ziens.

De droom van de dba: ontdekking en beheer in de omgeving