Door Techopedia Staff, 26 mei 2016
Takeaway: Host Eric Kavanagh bespreekt databasebeheer en instance-ontdekking met Robin Bloor, Dez Blanchfield en Bullett Manale in de nieuwste aflevering van Hot Technologies.
Je bent momenteel niet ingelogd. Log in of meld je aan om de video te bekijken.
Eric Kavanagh: Oke dames en heren. Welkom weer terug. Mijn naam is Eric Kavanagh. Dingen zijn hot. Het wordt hier warm. Ik weet niet wat er aan de hand is. Oh dat klopt, het is tijd voor Hot Technologies. Ja inderdaad, mijn naam is opnieuw Eric Kavanagh. Je kunt me vinden op Twitter @eric_kavanagh. Dit is de show die is ontworpen om te praten over wat hot is op de markt. De titel vandaag, "Keys to the Kingdom: SQL Server beheren met Dynamic Discovery." Goed spul. Er is echt die van jou. Oké, die foto was van een paar jaar geleden. Ik ga niet liegen, ik zie er nu wat ouder uit, maar dat is prima.
We hebben het dus over hoe technologieën en SQL Server echt heel, heel, heel erg heet zijn. We hebben vandaag een hele hoop inhoud, dus ik ga het meteen overhandigen. Stand-by, hier gaan we. Daar zijn onze sprekers. En Robin Bloor gaat eerst.
Robin Bloor: Ja inderdaad. De presentatie gaat dieper in op databasebeheer, dus ik dacht gewoon dat ik databasebeheer zou doorlopen, of, je weet wel, het database-doolhof, om mensen in de geest ervan te krijgen. Ik was ooit een DBA, ik veronderstel dat je zou kunnen zeggen dat ik een database-consultant was, ongeveer 20 jaar geleden, en het ding dat me eigenlijk verbaast over databases is dat er niet veel is veranderd. Er zijn veel dingen veranderd op het gebied van snelheid, op het gebied van de hoeveelheid gegevens en dat soort dingen, maar veel ervan blijft eigenlijk erg lijken op wat er vroeger gebeurde.
Een database is naar mijn mening een georganiseerde, uitbreidbare verzameling gegevens die kan worden geoptimaliseerd voor specifieke workloads en datamanagementmogelijkheden biedt. Het is in de eerste plaats ontstaan omdat als je gegevens in bestanden wilde beheren, het een ontzettend moeilijke taak was. En het idee om een stuk software samen te stellen dat vrijwel alles zou doen waarvoor je het nodig had, kwam vrijwel onmiddellijk op gang, zodra we in de jaren 70 willekeurige toegang hadden tot IBM-mainframes.
De relationele database werd uitgevonden in de jaren '70 en ontstond in termen van prototypes in de jaren '80 en kreeg een soort van grip op de markt vanaf het begin van de jaren '90. En relationele databases zijn nog steeds uiterst dominant in populariteit. Als je de pers leest, zul je heel veel dingen daarover horen zeggen - SQL-databases en recentelijk is er ontzettend veel ruis over grafische databases. En die zijn interessant, als je wilt, maar eigenlijk nog steeds in de nieuwste verkoopaantallen, hebben relationele databases 95% van de markt. En Microsoft SQL Server, die we vandaag uitgebreid zullen bespreken, is de op een na populairste van Oracle.
Het ding aan relationele databases dat ze ongebruikelijk maakt wat betreft de engines die ze zijn, is dat ze kunnen werken aan zowel OLTP- als query-workloads. Je moet ze anders afstemmen als je dat gaat doen, maar ze zijn in feite geschikt voor beide soorten werklast. Een daarvan is korte willekeurige transacties en de andere lange zoekopdrachten die veel gegevens bevatten. Het alternatief, de NoSQL-database en de grafische database, is voornamelijk voor analyse en ze zijn vrij recent gestegen. NoSQL kwam eerst en de grafiek begint de laatste tijd wat grip te krijgen. NoSQL kan worden gebruikt voor transactionele activiteiten, maar grafieken worden bijna nooit gebruikt voor transactionele activiteiten. De reden dat ik een stat tegenkwam die eigenlijk volgens mij minstens tien jaar oud is en die zegt dat de meeste bedrijven minstens drie hebben, eigenlijk waren dat 3, 5, verschillende merken databases, als je kijkt naar hun inventaris van software.
Maar de realiteit is dat de meeste bedrijven standaardiseren op een specifieke database. En de meeste bedrijven hebben gestandaardiseerd op SQL Server en Oracle als de twee meest populaire voor, als u wilt, standaarddatabases. En ze gebruiken de alternatieven alleen in uitzonderlijke omstandigheden, waar ze bijvoorbeeld een softwarepakket krijgen dat een andere database nodig heeft of ze gaan achter enkele van de bestaande big data-analysedoelen.
We hebben ook, als je wilt, de inmenging van Hadoop. Hadoop is op de een of andere manier meer dan een bestandssysteem geworden, maar nog geen database. Het heeft echter SQL die er bovenop zit. Maar het bewijs is dat het niet echt verdringt of in de buurt komt van het vervangen van de relationele databases die de harten en geesten van de wereld hebben verdiend. En de reden daarvoor is echt dat die relationele databases twintig jaar duurden, eigenlijk langer dan twintig jaar, om zo goed te worden als ze zijn. En u bouwt niet alleen een query-engine of SQL-engine die echt heel goed presteert in een zeer korte tijd. Het gebeurt gewoon niet.
En de conclusie van deze dia is dat databases strategisch zijn en dat ze evolueren, ze worden beter. En dat is zeker het geval bij Oracle en Microsoft SQL Server. U herinnert zich waarschijnlijk, weinigen van u, terug naar de dagen toen databases voor het eerst opkwamen, maar dat deed ik, toen was ik een jongen. Het oorspronkelijke idee was dat er een enkele database zou zijn en dat was een conceptueel idee dat absoluut nooit wortel schoot. IBM heeft met de AS / 400 een poging gedaan om daadwerkelijk een database-gebaseerd bestandssysteem te hebben, maar ook dat domineerde niet. Je blijft zitten met het feit dat databases van nature fragmenteren. Je hebt eigenlijk van nature meerdere instanties. Er zijn problemen met de schaalbaarheid. Database is alleen geschaald naar een bepaalde grootte, toegegeven dat de omvang in de loop der jaren is toegenomen, maar ze hadden grenzen.
En er waren problemen met de werkbelasting, het grootste probleem met de werkbelasting was dat OLTP-werkbelastingen en grote querywerkbelastingen gewoon niet compatibel zijn met elkaar. En het was onmogelijk om een motor te bouwen die dat zou doen. Wat we tegenkomen, wat best interessant is, kwam ik onlangs een site tegen die meer dan duizend verschillende exemplaren van Oracle had. Ik kan me niet precies herinneren hoeveel DBA's ze hadden, maar als je daadwerkelijk met ze sprak over hoeveel van die databases daadwerkelijk werden gecontroleerd door een DBA, was het ongeveer tien. Ze gebruikten de database in feite als een kast en gooiden er gewoon gegevens in omdat je tenminste een schema had en het meer georganiseerd was dan een bestandssysteem ooit zou zijn, maar niemand deed iets anders dan het een standaardconfiguratie geven en het instellen los.
Ik weet niet zeker of dat een goed idee was. Het klinkt bizar voor mij, om eerlijk te zijn, omdat naar mijn mening, wanneer ik met databases werkte, databases nodig hadden en je op een of andere manier precies moest weten wat er aan de hand was. En heel veel systeemafhankelijkheid betekent dat aan bepaalde soorten serviceniveaus absoluut moet worden voldaan, anders krijg je problemen.
Er is recent gesproken, ik ben verschillende databases tegengekomen die beweren dat ze zichzelf afstemmen. Degenen die kolomarchieven zijn die zijn ingesteld voor queryverkeer zijn grotendeels zelfafstemmend omdat er twee keuzes zijn die u moet maken met betrekking tot de indexen. Maar afgezien van dat specifieke gebied, moeten databases worden afgestemd. En ze moeten worden afgestemd, bepaalde relationele databases, vooral omdat bij heel veel transacties joins zijn betrokken. Joins zijn dure activiteiten. Als u de juiste indexen niet op de juiste plaats plaatst, nemen joins onnodig veel tijd in beslag als dat niet nodig is.
De zelfafstemmende databases zijn op dit moment alleen aanwezig in deze gebieden waar de workloads goed bekend zijn. En mijn ervaring is dat de meeste bedrijven maar weinig DBA's in dienst hebben en dat komt omdat ze duur zijn. En daarom is het beter als u kunt afwisselen met wat de DBA doet. Dit zijn de activiteiten van een DBA zoals ik ze begrijp. Ze doen installatie, configuratie en upgrade van databases. Upgrade is trouwens niet noodzakelijk een triviale activiteit. De reden dat je een database zou upgraden, ik bedoel, de regel waar ik altijd mee heb gewerkt is het niet aanraken als het werkt, en als je een database naar een bepaalde nieuwe versie gaat upgraden, doe je het in testmodus eerst en daarna upgrade je alles. Je hebt nog steeds te maken met dezelfde versie. Maar in feite zijn er veel sites die ik ben tegengekomen, dat is niet wat er gebeurt. Er is, laten we zeggen, een behoorlijke mate van entropie. Licentiebeheer is een probleem, hangt af van welke licentie je hebt. ETL en gegevensreplicatie.
Een van de trucs met de database is dat als u een queryworkload hebt die moet worden gesplitst, u twee instanties kunt maken en kunt repliceren en dat gebeurt vaak wanneer mensen de replica indien nodig als een hot backup gebruiken. Dan opslag en capaciteitsplanning, dat is onderdeel van de activiteit van een DBA omdat de gegevens natuurlijk groeien en dat moet u volgen. En dan moet u verschillende hardware-upgrades of hardware-uitbreidingen plannen. Er is probleemoplossing, wat een pijnlijke activiteit is voor de meeste DBA's. Waar iets misgaat en de back-up niet precies perfect werkt en dan moeten ze hun mouwen oprollen en naar beneden gaan en proberen dingen uit logbestanden te herstellen. Dat gebeurt veel vaker dan ik denk, nou, dat herinner ik me nog, maar ik heb het spel al minstens tien jaar uitgespeeld, maar ik herinner me dat het vaker gebeurde dan je ooit had verwacht. Prestatiemonitoring en -afstemming is gewoon het kloppende hart van een DBA-taak. Maar er is ook beveiliging op het gebied van toegangsbeheer, back-up en herstel, waardoor softwaretestsystemen worden gemaakt die redelijk vergelijkbaar zijn met een live-systeem. En de hele levenscyclus van gegevens. Dus dat is naar mijn mening de lijst met banen van de DBA, afgezien van al het andere dat hen zou kunnen worden gevraagd. Operationele dynamiek. Uiteindelijk zijn gegevensintegriteit en serviceniveaubeheer de primaire verantwoordelijkheid van de DBA. En normaal zijn ze kritisch. En dat is alles wat ik te zeggen heb. Ik ga het overhandigen aan Dez.
Dez Blanchfield: Heel erg bedankt. Ik ga ons meenemen op een beetje een leuke, anekdotische reis rond waarom het hele onderwerp waar het vandaag over gaat en kritischer is dan ooit. Nog niet zo lang geleden was ik betrokken bij een project waarbij we een overheidsplatform migreerden dat werd gebruikt voor kentekenregistratie en voertuigregistratie en een hele reeks dingen rond dat onderwerp, van een Fujitsu-mainframe-platform met een ding genaamd A + Addition, dat is een Solaris-besturingssysteem, oftewel Unix, waarop Oracle draait en het heel goed doet. En het uitzicht was dat dit ding oud werd en het was tijd om het naar iets anders te verplaatsen. We hadden veel plezier met het draaien van Unix op mainframe en het was zeer stabiel en zeer veilig en vreemd genoeg het SDL-platform en het was gewoon absoluut razendsnel. Maar wijsheid was dat het tijd was om van het mainframe af te stappen en te bewegen.
Deze belangrijke uitdaging is het in kaart brengen van alle systemen en bedrijfslogica en de SQL-omgeving voor de onderliggende databases en kijken hoe we een nieuw huis hiervoor zouden gaan ontwerpen en bouwen. En uiteindelijk hebben we het naar een van deze dingen gebracht die nu een paar jaar oud is, maar een van de top van het Sunfire-systeem Starfire-servers. En dit zijn waarschijnlijk enkele van de grootste tin die je op de planeet kunt kopen die allemaal in één grote doos en een symmetrische multiprocessing-server leven. Het was een mid-range systeem in onze wereld. Het draaide Unix en het draaide Oracle native en het uitzicht was: "Wat kan er misgaan?" Nou, het blijkt, veel.
Destijds bijvoorbeeld, en waar we het niet lang geleden over hadden, moesten we een heel handmatig proces doorlopen om te ontdekken wat er op het mainframe-platform stond en over te brengen. In het bijzonder de feitelijke databaseomgeving en de SQL-logica. Dus de opvatting was dat het een vrij eenvoudige Oracle-naar-Oracle-verplaatsing zou worden, database-naar-database-verplaatsing; alle bedrijfslogica zou overkomen, het grootste deel van de bedrijfslogica was geschreven in embedded queries en triggers, en hoe moeilijk zou het kunnen zijn? Maar iets dat maanden moest duren, duurde niet helemaal een jaar. Om gewoon fysiek en handmatig elk deel van de Unix in de mainframe-omgeving te doorlopen, te ontdekken waar alle databases waren en hoeveel exemplaren actief waren en wat er op die exemplaren draaide en het was een niet-triviale oefening en we deden het uiteindelijk drie keer om er zeker van te zijn dat we alles hadden vastgelegd. Omdat elke keer dat we dachten dat we zo diep hadden gegraven als nodig was, bleek er onder de oppervlakte meer te zijn.
De andere uitdaging die we hadden was welke instanties actief zijn en in welke staat? Is dit een ontwikkelomgeving? Is het een testomgeving? Is het onderdeel van het integratieproces? Is het systeemintegratie? Is het UAT, het testen van gebruikersacceptatie? Is het productie? Is het een DR-omgeving? Omdat het mooie van mainframes is, kun je deze kleine virtuele omgevingen bouwen die we nu allemaal als vanzelfsprekend beschouwen en dingen verplaatsen. En je moet uitwerken, is deze persoon bezig met het ontwikkelen en testen van productiekwaliteit, of doen ze productieproductie, zijn er echte gebruikers op dit gebied? Vergeet niet dat dit ding in realtime het uitgeven van rijbewijzen en autoregistratie en dingen die echt belangrijk zijn voor het leven van mensen doet.
En het duurde lang om back-ups voor dit ding uit te voeren, dus we hadden niet echt een onderhoudsvenster om het ding offline te brengen en te zien wat er gebeurde. Er bestond niet zoiets als omleiden. We hadden ook de uitdaging om niet alleen te achterhalen welke instanties werden uitgevoerd en waar en voor wie, maar vervolgens moesten we uitzoeken welke versies van welke instanties werden uitgevoerd. En hier verloor ik bijna mijn plot. Toen ik begon te beseffen dat we twee of drie versies van de productieomgeving hadden die verschillende testniveaus doormaakten en er weinig in de weg stond voor tools en systematische benaderingen hiervan. We moesten ons letterlijk verdiepen in de code en in de lopende instantie en in sommige gevallen het risico nemen om iets offline te nemen. We hebben deze hele zaak doorgrond, we hebben het in kaart gebracht en het was een heel handmatig proces zoals ik al zei. En uiteindelijk hebben we de hele ETL-verschuiving gemaakt, het van de ene plaats naar de andere gedumpt en naar een andere verplaatst en over het algemeen werkte het. En we waren van, oké, het is functioneel, we zijn er erg blij mee.
Maar toen kwamen we een aantal zeer serieuze bakstenen muren tegen. We vonden met name prestatieproblemen. En het verstandige denken van de dag was, nou, het is gegaan naar een grotere, betere, snellere, hardere hardware, er is geen reden waarom het slecht zou presteren op de applicatie op databaseniveau, dus laten we ergens anders gaan zoeken. Dus hebben we het netwerk twee keer volledig opnieuw ontworpen. Elke router, elke schakelaar, elke kabel, we zijn in sommige gevallen van Ethernet naar glasvezel gegaan, we hebben software geüpgraded, we hebben gepatcht, u krijgt het beeld. We hebben het netwerk in wezen twee keer opnieuw opgebouwd, omdat we dachten dat daar prestatieproblemen waren. En het zag eruit en voelde alsof het was. We hebben verschillende beveiligingssystemen doorlopen, verschillende firewalls. We hebben het besturingssysteem gepatcht. We hebben dingen van het ene rekenblad naar het andere verplaatst. En we hebben een aanzienlijke hoeveelheid tijd besteed aan het bekijken van de infrastructuur ervan.
En toen beseften we dat toen we de servers loskoppelden en er enkele andere applicaties op draaiden, het netwerk prima werkte. Dus begonnen we het besturingssysteem uit elkaar te halen. Zelfde probleem. Maar interessant, het netwerkniveau en het besturingssysteemniveau, de tools waren er, het was eigenlijk relatief eenvoudig voor ons om te benchmarken en te testen en te bewijzen dat elk van die onderdelen werkte. Maar zelfs toen, op de Solaris op mid-range op SPARC hardwareplatform, waren de tools er gewoon niet voor ons om de databaseomgeving te diagnosticeren. Weet je, in kaart brengen of we alle instanties hadden overgebracht. En dus moesten we eigenlijk onze eigen tools bouwen en wat schrijven en gaan zitten, of het nu binnen de database-tools zelf was in de eigen scripttalen of dat het een reeks shell-scripts was of in sommige gevallen een heleboel C-programma's.
We zijn eindelijk ingegaan op enkele zeer interessante kwesties waarbij de logica onder de SQL-laag, de eigenlijke database-engines zelf, bleek dat wanneer iets op een bepaalde manier werd gebouwd voor iets dat op de mainframe-versie van Oracle werd uitgevoerd, naar de Solaris op SPARC was gemigreerd versie Oracle transponeerde het niet meteen dezelfde prestaties. Dus dit was in de eerste plaats een behoorlijk pijnlijke reis, gewoon doen en alles vinden, maar nu moesten we het diagnosticeren op het nieuwe productiesysteem en opnieuw blies dit ding de migratie van een maand uit tot bijna een jaar. En het kwam er gewoon op neer dat we de tools niet hadden. Rennen rond dingen te doen zoals proberen metadata in kaart te brengen.
Op een gegeven moment besloten we bijna dat we een Ouija-bord nodig hadden, omdat het op die manier gemakkelijker zou worden om gewoon willekeurig te wijzen en te porren. Eenvoudige dingen zoals uitzoeken wie toegang had tot de oude systemen en waarom zij die toegang hadden. En wie de toegang tot de nieuwe nodig had en die bevestigde, iemand liet afmelden en bevestigen en die in kaart bracht. Zelfs iets eenvoudigs als de grootte van de database was niet consistent tussen de twee platforms. We moesten een tool bouwen om dat te doen en een vergelijking maken tussen hoe groot de database is in tonnage, in ruwe megabytes of terabytes op Systeem A versus Systeem B. En in meer detail duiken rond prestaties en de performante omgeving. Nogmaals, moest nieuwe tools bouwen. Er was gewoon geen standaard voor ons.
En hier krijg je deze hele boodschap uit, toen we aan het eind kwamen van het ding en we het stabiel kregen, elk stuk ervan was een zeer handmatig proces, de enige manier waarop we iets konden automatiseren was als we een nieuwe tool of nieuw script. En als we de tools hadden die vandaag beschikbaar zijn, zou het leven zoveel gemakkelijker en zoveel beter zijn geweest. En we zouden miljoenen hebben bespaard op dit project. Maar ik denk dat waar we het vandaag over hebben, het feit is dat de tools nu beschikbaar zijn en ze maken het leven zoveel gemakkelijker. Veel van de valkuilen zijn nog steeds aanwezig. Ontdekking van de databases die er zijn en welke instanties welke uitvoeren. In welke staat zijn ze. Hoeveel lopen er? Waarom rennen ze? Of ze goed rennen. Worden ze geback-upt?
Dit zijn allemaal dingen die we op veel manieren als vanzelfsprekend kunnen beschouwen met de juiste tools. Maar er was een periode in deze specifieke anekdote zoals ik zei, waar dat iets was waar velen van ons veel haar verloren, we namen waarschijnlijk vijftien jaar van ons leven af en betreurden het feit dat de tools er nu niet waren . En ik kijk ernaar uit om daar vandaag nog veel meer over te horen van onze gast, Bullett. Dus daarmee, Bullett, ga ik je doorgeven en ik kijk ernaar uit om te horen hoe je dit probleem hebt opgelost.
Bullett Manale: Oké. Klinkt goed. Eric, laat me het hier met de dia's overnemen en een beetje praten over, heel snel, Idera, het bedrijf, voordat we in het product zelf stappen. Net als een FYI is dit een soort portfolio van verschillende producten die we beschikbaar hebben.
Eric Kavanagh: Je audio is nogal heet, dus als je een headset gebruikt, trek je die een beetje omhoog.
Bullett Manale: Geen probleem. Is dat beter?
Eric Kavanagh: Dat is veel beter. Haal het weg.
Bullett Manale: Oké. Dus vandaag gaan we ons concentreren op de Inventory Manager, die duidelijk is afgestemd op veel van deze onderwerpen die we bespreken. Ik wil je alleen een beetje inzicht geven in hoe dit product is gekomen waar het is. We zijn begonnen met het dagelijks kijken met onze productlijn, we hebben een performance monitoring tool genaamd Diagnostic Manager. We hebben een Compliance Manager-tool. Dus, veel verschillende tools rond SQL Server en onvermijdelijk stellen we altijd de vraag voor licentiedoeleinden: "Wat is het aantal instanties dat u momenteel binnen uw organisatie beheert?" En het interessante was dat we daar nooit echt een stevig antwoord op konden krijgen. Het maakte niet echt uit met wie je sprak. Het was altijd een beetje: "Wel, we denken dat het rond dit aantal ligt." Dat soort dingen kwamen altijd binnen en dan zouden we dit proces moeten doorlopen om erachter te komen wat ze precies hadden waarvoor ze een licentie wilden hebben in termen van de instanties die we beheren.
We hebben duidelijk heel snel ontdekt dat er bij veel DBA's wat pijn aan lijkt te kleven. Als DBA is een van de dingen waarvoor ze verantwoordelijk zijn natuurlijk dat ze weten, omdat ze zich zorgen moeten maken over hun licentieovereenkomsten, in dit geval met Microsoft en SQL Server. Het is duidelijk dat ze nog veel andere gebieden hebben waarvoor ze verantwoordelijk zijn, maar dat is een van de dingen die nogal een groot ticketitem is in termen van als een DBA wat je algemene verantwoordelijkheden zijn. Daarmee zijn we eigenlijk tot de conclusie gekomen dat we een tool nodig hebben die het voor een DBA gemakkelijk maakt om dat aantal echt te begrijpen. Omdat je SQL-verspreiding hebt als je dat zo wilt noemen en het gebeurt om een aantal verschillende redenen. Er is misschien niet zoveel controle over wie de software installeert en dat soort dingen.
En het ergste dat kan gebeuren, is dat iemand een exemplaar van SQL Server in handen krijgt, het installeert, ermee begint te werken zonder enige kennis van sommige andere organisaties of afdelingen in het bedrijf, en dan het volgende dat u weet, misschien er wordt geen back-up gemaakt van de gegevens en dat soort dingen die kunnen gebeuren. Waar je nu nog een probleem hebt, waar je situaties zult hebben waarin je kritieke gegevens gaat verliezen omdat je niet weet dat de instantie überhaupt bestaat.
Een van de dingen die we moesten doen was zeggen, laten we het ontdekkingsstuk ervan uitzoeken. En bovendien dat we de informatie die we verzamelen op een logische manier kunnen organiseren en beheren op basis van wat de onderneming doet. En dan duidelijk daaruit beslissingen kunnen nemen rond die informatie en dat soort dingen kunnen doen. Dat is een soort van waar de tool begon en waar het vandaan kwam. Ik kan je vertellen dat we, door regelmatig met DBA's te praten, echt het probleem hebben dat we niet weten hoeveel instanties ze hebben.
En het is grappig omdat, de term, je kunt niet beheren wat je niet kunt meten, altijd met prestatiehulpmiddelen kwam die we hebben, zoals SQL Diagnostic Manager, maar je kunt echt niets beheren als je dat niet weet "Het" zelfs daar in de eerste plaats. Dus dat is ook een groot deel van deze tool, gewoon kunnen weten dat het er is.
Overigens, in gesprek met enkele van de grotere organisaties of enterprise-winkels met SQL Server, was het interessante dat we met veel jongens tegenkwamen dat we spraken, dat ze eigenlijk een tijd hadden ingesteld in de loop van hun jaar waarin ze liepen eigenlijk fysiek van de ene plaats naar de andere om te proberen te bepalen hoe dat aantal eruit ziet. Je kunt je voorstellen dat je als DBA een behoorlijk goede hoeveelheid geld krijgt om in sommige gevallen fysiek van de ene machine naar de andere te lopen, wat verrassend was wat we zouden horen van enkele behoorlijk grote bedrijven die ik niet zal noemen. Maar het is gewoon een interessant punt dat je twee weken per jaar aan dit soort oefeningen kunt besteden, alleen om erachter te komen of hun aantal licenties correct is.
Dit is allemaal gerelateerd aan deze tool en hoe het helpt, maar de manier waarop we dat hebben aangepakt, was door de mogelijkheid om ontdekkingen te doen op basis van een aantal kenmerken van SQL Server. En dus is de eerste vraag: waar wijs je naar of waar probeer je eerst naar te kijken? De manier waarop we dat deden was te zeggen, laten we het doen op IP-bereik of we kunnen het doen door het lidmaatschap van het domein zelf in termen van de computers die lid zijn van het domein. Dat is een soort van hoe we dat deel hebben aangepakt, alleen om te kunnen zeggen dat dit het gebied is waar we ons op willen concentreren in termen van ontdekking.
En dan is het andere deel daarvan gebaseerd op die kenmerken, de poorten en andere dingen, WMI-registersleutels en dat soort dingen, we kunnen verzamelen en vaststellen dat SQL waarschijnlijk op die instantie of die specifieke omgeving wordt uitgevoerd en geïnstalleerd. Het is duidelijk een veel betere methode dan de sneaker-methode of sneaker express-methode. Het leuke is dat al die informatie die we over de instantie verzamelen, in een repository wordt bewaard en dat deze kan veranderen als de omgeving verandert. Het gaat niet alleen om: "Hé, er is een instantie, hier is een lijst die we hebben gevonden", maar het is als de DBA, of de persoon die de instanties beheert, om te bepalen of ze dat deel van de inventaris willen maken, en wanneer het maakt geen deel uit van de inventaris om die instantie te kunnen buiten gebruik stellen. En dus hebben ze de levenscyclus van het hele proces van de SQL Server-instantie om echt gemakkelijk te begrijpen binnen de tool.
Als we eenmaal de instanties hebben ontdekt, wat doen we daarna? Het andere is veel van de informatie over het exemplaar, ik wil het niet handmatig gaan ophalen en in een spreadsheet of dat soort dingen plaatsen. En dat is nog iets dat interessant was om met DBA's te praten over het inventarisatieproces en de licentie, dat je verbaasd zou zijn over hoeveel DBA's ik sprak toen je hen vroeg: "Hoe onderhoud je je voorraden?" En we praten met DBA's, wat echt het ironische deel ervan is, dat ze dat bijhouden en dat bijhouden in een statische spreadsheet van alle dingen. Zoals ik al zei, het is heel ironisch als je daar even over nadenkt. Maar dat was in veel gevallen en bij veel organisaties is dat nog steeds het geval. Hoe ze dat houden. Het is een hoofdkopie van een Excel-spreadsheet die ronddrijft en regelmatig moet worden bijgewerkt.
Dat waren de dingen die een uitdaging vormden en dus door die instantie te registreren en deel uit te maken van de inventaris, kun je dat doen en de informatie ophalen. Je kunt het laten automatiseren of het al dan niet onderdeel wordt van de inventaris, de versie, de editie, en de andere dingen die je ermee kunt doen zijn dat je misschien handmatig die lijst of Excel-spreadsheet kunt toevoegen. U kunt dat importeren in deze tool genaamd SQL Inventory Manager. Als u al een beginpunt hebt van instanties waarvan u het gevoel hebt dat u er vrij zeker van bent, kunt u die instanties importeren in en vervolgens dat deel van uw beheerde voorraad in het product opnemen. Als we eenmaal de instantie hebben en als we eenmaal weten dat het er is, dan wordt het goed, we hebben veel informatie die we kunnen gebruiken door te weten dat die instantie er is, door eropuit te gaan en die informatie te verzamelen.
En veel informatie zal nodig zijn voor meer dan alleen licentiedoeleinden. Veel ervan kan natuurlijk worden gebruikt om gewoon te weten waar dingen zijn, om door deze informatie te kunnen zoeken nadat deze is verkregen. Maar het belangrijkste is de server, de hardware zelf. In staat zijn om te begrijpen wat voor soort machine het is, misschien het model of de fabrikant, het geheugen, de hoeveelheid geheugen, of het nu een fysieke of virtuele machine is en vooral het aantal fysieke sockets of cores en CPU's en dat soort dingen.
In termen van het aantal cores, vooral met SQL Server, is het kennen van de manier waarop ze hun licenties doen nu per-core berekeningen in de nieuwere versies van SQL, dat wordt een heel belangrijk onderdeel ervan en het is niets dat je hebt om uit te gaan en er daadwerkelijk naar te gaan graven. Zodra het exemplaar is geïdentificeerd, kunnen we die informatie verstrekken en eruit halen en u laten bekijken en begrijpen en er uiteraard van profiteren.
De volgende laag is op de instantie die duidelijk een groot aantal van de SQL Server-instantie heeft, of deze nu standaard of enterprise of zelfs express is, of de gratis versie van SQL Server. Ook kunnen begrijpen welke applicaties aan dat exemplaar zijn gekoppeld en dit kan automatisch worden gedaan. De configuratie-instellingen en dat soort dingen kunnen begrijpen, evenals andere stukjes informatie die betrekking hebben op het exemplaar van de SQL Server zelf.
Vervolgens ga je naar de eigenlijke database en zie je de configuratie-instellingen, de hoeveelheid ruimte die aan die gegevens is gekoppeld, waar deze zich bevindt, wordt al dit spul automatisch ingevuld en dat is een enorme tijdsbesparing. En nogmaals, omdat het dynamisch uitgaat en dagelijks nieuwe exemplaren identificeert, is het iets dat je hebt met betrekking tot je inventaris. Dat is eigenlijk het doel van het product om het zo te maken, het iets te maken dat dynamisch verandert.
Zodra al deze informatie beschikbaar is voor ons en we al deze gegevens kunnen ophalen, is het echt zinvol om in sommige gevallen uw eigen metadata te maken die aan deze instanties zijn gekoppeld en die metadata kunnen worden gemaakt op een manier die stemt overeen met de manier waarop u zaken doet.
Dus als je je instanties hebt gegroepeerd op geografische locatie, of door applicatie-eigenaren of door DBA-eigenaren of wat dan ook, is het misschien in termen van hoe je die exemplaren wilt groeperen, hoe je logisch zinvol wilt zijn om die exemplaren te begrijpen, dan is er van twee gebieden in de tool die je die mogelijkheid geven.
De eerste is de mogelijkheid om een tag van bijvoorbeeld, of een tag te maken. Dat is in wezen het creëren van een koppeling met de server, het exemplaar of de database, zodat u weergaven kunt maken en vragen kunt beantwoorden die dagelijks kunnen worden gesteld, waardoor u echt grip krijgt op wat u hebt, wat u beheert en hoe u met die informatie verder wilt gaan.
Het andere dat we hebben is iets dat inventarisatievelden of aangepaste inventarisatievelden wordt genoemd en deze zijn specifieker voor het soort informatie dat u kunt doorboren, bijvoorbeeld de databaselaag die ik zou kunnen besluiten om een vervolgkeuzelijst toe te voegen alle DBA's en ik kunnen bepalen wie verantwoordelijk is voor die database, afhankelijk van dat soort situatie of wat dan ook, welke database het ook is met wie verantwoordelijk is, kan dat selecteren, zodat ik weet dat zij degenen zijn die verantwoordelijk zijn en heel eenvoudig door gewoon in de inventaris te graven.
Dus deze stukjes informatie worden erg waardevol, vooral als je een grote omgeving hebt, omdat het je alleen helpt om die informatie te begrijpen en te weten wat je hebt en hoe je het doet.
Dus laat me doorgaan en overschakelen naar de volgende dia hier. Wat ik je nu laat zien, is dat al deze informatie die we verzamelen, al deze informatie en gegevens die we verzamelen en metadata toepassen je de mogelijkheid geeft om dan veel eenvoudiger en sneller beslissingen te nemen als het gaat om verhoog uw licenties bij Microsoft in de onderneming volumelicenties of softwareverzekering bij Microsoft.
Dat maakt het voor jou heel gemakkelijk om dit te doen in plaats van dat je moet gaan en veel handmatige gegevensverzameling moet doen, veel handmatige verzameling van die informatie die het eigenlijk gewoon een stuk beter maakt. Dat is dus een van de mandaten van het product, soms om het de DBA's gemakkelijker te maken om die beslissingen over licenties te nemen.
Het andere dat we, soort van praten met DBA's, heel snel ontdekten en leerden, is dat - en het is een beetje teruggaan naar wat eerder werd besproken - je misschien 300 exemplaren in je omgeving van SQL Server hebt, maar er is echt misschien alleen een subset van degenen die echt volledig worden gemonitord en beheerd vanuit een traditionele tool voor prestatiecontrole.
Dus als je gaat en je gaat echt zitten met de DBA en je zegt: "Kijk, we weten dat je deze 20 exemplaren of 10 exemplaren van de 300 hebt die worden gemonitord met deze tool die is ontworpen om dat te controleren en te voldoen aan je SOA's en meldingen ontvangen en al dat soort goede dingen, "wat we ook vonden is dat als je vroeg:" En hoe zit het dan met die andere 280 instanties die je hebt? Ben je daar bezorgd om? 'En ze geven om hen, maar ze willen gewoon niet per se een investering doen om die te monitoren op het niveau van diepte dat kan worden gedaan met die instanties versus die 10 of 20 echt, echt kritische productinstanties.
Het andere deel van de vergelijking met deze tool is dus dat het ook helpt om ervoor te zorgen dat je op een basisniveau bijvoorbeeld wordt gedekt in termen van de gezondheid. Nu zal het je niet vertellen of je een impasse hebt of wie het slachtoffer van de impasse is. Het is niet om dat niveau van de sessies zelf en de details van de vragen te bereiken. Maar tegelijkertijd laat het je dat nog weten, hey de server is down of hey het volume vult of je moet back-ups van de database maken, dat is een soort van een belangrijk onderdeel van een DBA zijn.
Dus dat soort dingen zijn zeker nog steeds belangrijk en dus maakte het met dit hulpmiddel een manier voor je om een catch-all te hebben voor je echt kritieke instanties die veel, heel veel waard zijn, als ze gaan moet je dat meteen weten. Ze kunnen een hoger niveau van monitoring hebben en in staat zijn om dat soort dingen te doen, terwijl het hiermee in staat zal zijn om nieuwe instanties op te pikken die aan de omgeving zijn toegevoegd en ervoor te zorgen dat ze worden verantwoord en ook zeker dat die basisniveaus van gezondheidscontroles worden gevormd.
Dus dat is een beetje in een notendop waar de Inventory SQL Import Manager om draait. Nu ga ik je er een demonstratie van tonen. Voordat we dat doen, laat ik je snel zien dat dit de architectuurdia hier is en alleen om dit te laten zien, de voorbeelden van SQL die we beheren, kunnen we alles ontdekken, van SQL 2000 tot de nieuwe versies van SQL.
Dus we kunnen dat doen zonder ooit agenten in te zetten voor de instanties zelf. We doen het via een incassoservice en het gaat erop uit om die informatie te verzamelen en in een repository te plaatsen en dan kunnen we vanaf een front-end console van de Tomcat-webservice vervolgens met die gegevens communiceren en deze bekijken. Het is dus een vrij eenvoudige architectuur.
Ik ga je gang en schakel over en neem ons daadwerkelijk mee naar het product zelf, zodat je er een gevoel voor kunt krijgen, een begrip van hoe het werkt. Dus de beste manier om dit te doen, is om u eerst in de eerste plaats kennis te laten maken met de interface. Dit is een soort dashboard dat we hier bekijken.
Ik zie nu dat het aantal instanties dat ik onder beheer heb, niet zo veel is. Maar ik heb ook geen heel datacenter in mijn achterzak. Dus ik heb ongeveer zes instanties die we hier zien. Nu, dat gezegd hebbende, ben ik, wat ik ga doen, het ontdekkingsproces doorlopen en laten zien hoe het zou werken.
Nu is het eerste wat u zou doen in de administratie sectie kunt u aangeven hoe u uw instanties zou willen ontdekken. Je zou die informatie hier kunnen invoeren en dat kan weer via een reeks IP-adressen. U kunt een domein of subdomein aanwijzen en alleen op die machines die lid zijn van dat domein in staat zijn om die controles uit te voeren die u zou kunnen kiezen voor een aantal verschillende soorten kenmerken van wanneer SQL wordt uitgevoerd om op te controleren.
Als je dat eenmaal hebt gedaan, kun je het geautomatiseerd laten uitvoeren op een dagelijkse basis om die gegevens te verzamelen. Je zou het ook op ad-hocbasis kunnen doen als dat nodig is. Maar zodra je daarmee bent begonnen, zul je dat ontdekkingsproces gaan zien wanneer je naar het exemplaar van instanties hier gaat. U hebt een tabblad Ontdekken en het tabblad Ontdekken gaat ons die instanties tonen die recent zijn ontdekt. Dus in ons geval hebben we hier een nummer. Wat ik ga doen en doen is, ga je gang en voeg degene toe die we gaan gebruiken als voorbeeld. Dus dit is in dit geval een Chicago-exemplaar, toch? Ik ga door en voeg dat exemplaar toe aan mijn inventaris.
Oké en het zal me hier door een paar dingen heen helpen. Ik ga gewoon door en je zult zien dat we de referenties kunnen instellen. Mijn gegevens moeten daar goed zijn. Ik ga door en je zult merken dat ik het eigendom hiervan kan toewijzen als ik dat wil. Ik kan ook een locatie opgeven. Nu kan de locatie zelf ook worden toegevoegd, en dat zal de volgende keer duidelijk onthouden.
Nogmaals, ik kan hier ook tags aan koppelen in termen van de metadata en hoe we deze exemplaren van SQL, met name deze, in welke emmers we willen stoppen. Dus we hebben een aantal huidige tags, populaire tags, dus we kunnen een aantal verschillende tags bekijken die ik misschien al had opgenomen. Ik ga er gewoon een paar willekeurig kiezen en we kunnen dat toepassen.
Dus nu wanneer ik doorga en dit aan de inventaris toevoeg. Nu het is toegevoegd, zien we het nu verschijnen onder deze beheerde weergave en kunt u het hier hier zien staan. Dus je weet dat dat de eerste stap is en wat ik je net heb laten zien, was de manier waarop je die instanties vooral zou toevoegen als je er dagelijks doorheen gaat. In sommige gevallen zou je kunnen zeggen dat je weet wat als het een enterprise-editie van SQL Server is die ik automatisch wil toevoegen aan mijn inventaris? Ik hoef niet handmatig te gaan en ervoor te kiezen dat te doen.
Jocelyn: Ik ga je heel snel onderbreken. We zien uw demo niet.
Bullett Manale: Dat ben je niet?
Jocelyn: Nee.
Bullett Manale: Nou, dat is niet goed, laten we eens kijken.
Eric Kavanagh: Als je naar de linkerbovenhoek gaat, klik je op start, klik je daarop.
Bullett Manale: Ah, oké.
Eric Kavanagh: En deel nu het scherm.
Bullett Manale: Sorry daarvoor. JEP.
Eric Kavanagh: Dat is goed. Goede vangst daar, producent Jocelyn.
Bullett Manale: Oké, is dat beter? Zie je het nu?
Robin Bloor: Ja inderdaad.
Bullett Manale: Oké, dus laten we je een beetje doorleiden waar we heel snel waren. We hebben de ontdekte voorbeelden die we eerder hebben gehad. Ik heb zojuist de Chicago-instantie toegevoegd en wat je nu ziet, staat nu hier vermeld. Merk op dat het al veel extra informatie heeft verzameld. Als ik op het exemplaar zelf klik, krijg je alle soorten informatie te zien die we al over dat exemplaar hebben verzameld. Hier is een lijst met alle databases die er zijn. We zien een uitsplitsing van de databases naar grootte en per activiteit in termen van welke de meeste van een grootte en activiteit hebben.
Nogmaals, we kunnen je ook meteen vertellen welke applicaties we op die instantie zien draaien op basis van de werklast die we op de instantie zien draaien. Het is dus best leuk om dat automatisch te kunnen doen. Ik hoef niet naar binnen te gaan en de toepassing te koppelen aan de incidentie. Op basis van wat we zien, kunnen we dat invullen. Als u nu handmatig een toepassing wilt toevoegen, kunt u dat absoluut doen. Maar het is gewoon een leuke manier om de koppeling van het exemplaar aan de database of, helaas, aan de toepassing te tonen.
Je zult ook merken dat we aan de rechterkant van het scherm een onmiddellijk overzicht hebben en onderaan dat we een serveroverzicht hebben. Dus we hebben het hier over de belangrijkste stukjes informatie hier, de versie kennen en niet alleen, weet u, de SQL Server 2012, maar het werkelijke versienummer dat, inclusief en ons vertelt welke hotfixes eraan zijn gekoppeld, welke servicepacks eraan verbonden zijn, kan het heel belangrijk zijn om te weten. Het is duidelijk dat geheugenvereisten belangrijk zijn. Alles zoals dat, of het geclusterd is, al deze informatie, ik hoef het niet in te voeren - het wordt al verzameld en verzameld, en zodra we vaststellen dat het een ontdekt exemplaar is, zal dat deel uitmaken van onze inventaris.
Het andere dat je hier zult zien - en het zal je laten zien - het is in deze instantieweergave. We hebben deze kenmerken waarover ik eerder heb gesproken, de aangepaste kenmerken die kunnen worden toegevoegd. Dus we kunnen open soort tekstvakvelden toevoegen, we kunnen ja / nee doen met betrekking tot, je weet wel, een miljard soorten keuzes. We kunnen zelfs vervolgkeuzelijsten maken. U kunt dat doen op het exemplaar van de database of op serverniveau.
Als we vervolgens een beetje verder naar beneden scrollen, kunnen we alle gerelateerde informatie naar de server zelf zien. Dus je weet dat al dit soort dingen natuurlijk heel, heel nuttig is, omdat het allemaal verzameld en verzameld is en het is er voor ons zodra we die beslissing nemen om het onderdeel van onze inventaris te maken. Hier kunnen we enkele verschillen laten zien in termen van de CPU's, het aantal logische versus fysieke, hoeveel geheugen. Dus u krijgt echt een heel goede en schat aan informatie zonder veel werk te doen.
Het andere deel hiervan is, zoals ik al zei, dat we deze gegevens verzamelen op het exemplaar van het serverniveau. Als we zelfs naar de database gaan, zien we dat veel van dit spul ook voor ons is afgebroken. Dus als ik naar mijn compository-repository ga, zou ik in dit geval kunnen zeggen, nou ja, dit gaat om een, dit is een compliancedatabase waaraan het niveau van compliance of wettelijke vereisten is gekoppeld en het zou kunnen zijn, laten we zeggen, SOX-conformiteit of PCI-conformiteit. Dus ik kan kiezen welke databases aan welke compliance zijn gekoppeld die ik moet invullen of ervoor zorgen dat ik deze in overeenstemming met die wettelijke eis onderhoud.
Dus dit soort dingen is zeer nuttig gebleken voor DBA's, omdat er een plek is waar ze centraal naartoe kunnen gaan om al deze bijbehorende metadata gemakkelijk in hun omgeving te houden en ze kunnen, zoals ik al zei, zich conformeren aan hun bedrijf omdat ze ' opnieuw doen, zoals de manier waarop ze zaken doen. Dus als we naar alle dingen kijken die we tot nu toe hebben gezien, heb je natuurlijk een redelijk goed overzicht van de instantie, als ik er op in ga.
Ik kan ook zoeken, dus ik zei, laten we naar die nalevingsrepository zoeken in mijn inventaris. Wat je hier zult zien, is dat ik naar deze dingen kan zoeken en ze kan identificeren. Ik zeg dat - ik weet niet zeker wat, mijn go-knop werkt daar niet. Oke. Eens kijken, laten we dat nog eens proberen. Daar gaan we. Dus we zouden dan een uitsplitsing kunnen zien van waar we iets zien met onze compliance in en ik kan er dieper op ingaan en het ook vanuit dat standpunt bekijken. Dus je hebt een heel snelle en gemakkelijke manier om deze gegevens in te graven.
Zoals we eerder al zeiden, heb je veel verschillende manieren om metagegevens te maken voor de instantenserver en de database. Het andere deel is dat je daarvan kunt profiteren door de manier waarop je het hebt gegroepeerd en hoe je eraan bent gekoppeld. We gaan naar de verkennerweergave, dat kunnen we precies doen. We kunnen zeggen dat ik een database op locaties wil tellen. Dus het aantal databases op elke locatie van de omgevingen die ik ondersteun. Of misschien is het gebaseerd op de eigenaar die eigenaar is van de instanties die ik daar heb in termen van bijvoorbeeld instantie tellen. Dus we zullen dat kunnen zien. Dus je krijgt een heel goede, gemakkelijke manier om deze foto's voor je te schilderen op basis van de vraag die je op dat moment probeert te beantwoorden.
Wat u die informatie dan heeft gemaakt op de manier die u wilde, we kunnen het exporteren naar PDF of verschillende formaten om het te kunnen gebruiken en naar onze collega's te sturen of te doen wat we nodig hebben. Dus je weet dat je dat soort dingen kunt doen. Laten we teruggaan naar - ben ik het kwijt? Daar gaan we. Oké, hopelijk is dit logisch in termen van waar ik het tot nu toe over heb gehad. Nu de gegevens die we hebben verzameld, is dit allemaal om een aantal redenen heel belangrijk: licenties en wat dan ook.
Het laatste ding dat we alleen maar moeten vermelden, is dat we hier naar dit gedeelte van de administratie gaan. Hier kunt u ook uw e-mail en uw meldingen configureren en ervoor zorgen dat u voor die dingen die u echt wilt weten, ook die dingen kunt instellen. Dus we kunnen e-mailmeldingen instellen, we kunnen de mogelijkheid instellen om bepaalde dingen in te schakelen en bepaalde dingen uit te schakelen en vervolgens kunnen bepalen wie die e-mails zou ontvangen, en door ons te abonneren op die meldingen kunnen we associëren wie we zouden willen om te zijn, wie zou willen weten over dat soort dingen.
Maar zoals ik al eerder zei, dit is echt een leuke manier om te doen, tenminste algehele gemoedsrust te weten voor je hele enterprise SQL-exemplaren - wat het is dat je hebt en er ook voor zorgen dat het optimaal werkt, zelfs als je ' t, hebben niet de beslissing genomen om een investering te doen in een zware tool voor het bewaken van prestaties om die instantie te beheren. Dit gaat je dekken, omdat het een zeer betaalbare manier is om uit te gaan en in veel gevallen deze inventarissen kan doen en een soort van een zeer breed soort algemeen niveau van monitoring kan doen om ervoor te zorgen dat je heb die gemoedsrust en weet wat er aan de hand is.
Dus hopelijk is dat logisch in de manier waarop we het hebben beschreven en aan je hebben laten zien. Ik denk dat ik vanuit dat standpunt kan doorgaan en het terug kan geven en we kunnen wat meer praten.
Eric Kavanagh: Dat klinkt geweldig. Dus Robin? Dez? Nog vragen?
Robin Bloor: Nou, ik heb vragen. Het is eigenlijk heel interessant, ik bedoel, ik wilde alleen maar de opmerking maken dat ik vrijwel overal ben geweest, niet alleen bij de DBA's, maar bij de jongens van het netwerk, bij de jongens van de opslag, bij de mannen van het beheer van virtuele machines, ze ' werken allemaal vanuit spreadsheets.
Eric Kavanagh: Dat klopt.
Dez Blanchfield: Je weet een beetje dat dat is, je weet een beetje dat dat goed is totdat de cijfers beginnen te bewegen. Wanneer de cijfers beginnen te bewegen, weet je dat ze in de problemen komen. Dus de vraag waar ik nu een beetje in geïnteresseerd ben en ik weet dat het moeilijk voor je zal zijn om te antwoorden, maar wat als je ergens naar toe gaat waar ze niets dergelijks hebben voor het werken met spreadsheets, dus laten we aannemen de DBA's zijn erg slimme jongens enzovoort, wat voor ROI denk je dat je zou krijgen als je zoiets implementeert? Heb je daarover cijfers of richtlijnen daarover?
Bullett Manale: Het is moeilijk te zeggen wat de ROI is omdat de omgeving een beetje anders zal zijn. Het is duidelijk dat hoe groter de onderneming, hoe groter de omgeving, uiteraard hoe meer de ROI waarschijnlijk zal zijn als ze nu handmatige methoden gebruiken.
Ik weet wel dat ik met een aantal heb gesproken - wanneer ik grote organisaties zeg met duizenden en duizenden werknemers en waarschijnlijk ook met duizenden instanties - waar ik mensen heb waar ik dit aan hen laat zien en zij zeggen dat dit nodig zal zijn twee weken van mijn tijd terug. Ik heb dat meer dan eens tegen me gezegd. Dus het is moeilijk te zeggen in termen van het werkelijke dollarbedrag van een aankoop, maar het is aanzienlijk als je de omgevingen hebt.
Zoals ik al zei, het is redelijk consistent, het zijn de mensen met wie ik, de meeste mensen waarmee ik praat, dit soort dingen in een spreadsheet bewaren. Het is dus gewoon een heel, heel subjectief iets, omdat het in elke omgeving een beetje anders is wat betreft de manier waarop ze hun licenties uitvoeren en hoe ze hun licenties bij Microsoft uitvoeren is een ander onderdeel ervan, dat is een factor. Maar als ze elk jaar of om de drie jaar true ups moeten doen, denk ik dat Microsoft er maximaal drie jaar over doet, ze willen dat je je tenminste om de drie jaar waarmaakt.
Dan weet je dat het aanzienlijk is en weet je dat het gewoon iets is dat een stuk eenvoudiger maakt. Omdat het een dynamisch ding is dat altijd verandert, geeft het ook een beetje meer geldigheid in termen van wat je bekijkt, goed, we hebben de spreadsheet niet echt in zes maanden of een jaar bijgewerkt. Dus hoe vaak u de spreadsheet bijwerkt, is een andere vraag om te begrijpen dat het antwoord op de ROI.
Dez Blanchfield: Ja, ik bedoel, SQL-licenties, de licenties hiervan zijn gewoon een verdomde nachtmerrie, maar het is vooral een nachtmerrie omdat de licenties niet hetzelfde zijn tussen Microsoft en Oracle en iedereen die database-dingen doet. Als je eigenlijk dingen in spreadsheets bewaart die meestal zijn wat er echt gebeurt, weet je dat licentietijd voorbij komt voordat je het echt beseft en je hebt niet echt de gegevens, als je begrijpt wat ik bedoel, om gemakkelijk te krijgen bij die informatie.
Hoe dan ook, zoals u aangeeft, het is dynamisch en ik heb geen idee persoonlijk omdat ik eigenlijk nooit met Microsoft heb moeten onderhandelen, dus ik heb geen idee, maar vermoedelijk zijn er databases waarin mensen de testgegevens vrij vaak verwijderen, testen omgevingen en ik denk dat dat een doorn in het oog is als je licenties uitvoert. Ben jij dat-?
Bullett Manale: Ja, ja. Dat is het geval, omdat dat soort dingen vaak wordt vergeten en dan proberen we uit te zoeken, oke, oke oke we hebben kernlicenties dat we het aantal kernen voor elk van deze instanties moeten achterhalen en ik don Ik weet niet dat je, wat betreft de normen voor wat je koopt qua hardware, net zo goed goede hardware kunt kopen. Als je die hardware niet gebruikt zoals het zou moeten, dan betaal je teveel omdat je betalen voor kernprijzen wanneer die kernen niet worden gebruikt, dus dat wordt een probleem.
Dus de, elke versie van SQL heeft een andere manier waarop licenties worden toegepast, wat het zelfs een beetje verwarrend maakt. Dus je hebt daar wat uitdagingen mee en dat is een groot deel van de reden waarom deze informatie erg nuttig is, omdat we je kunnen vertellen welke versie het is, we kunnen je duidelijk vertellen het aantal cores dat je hebt, als het oudere versies van SQL zijn dat was de prijs per socket, dat kunnen we natuurlijk ook duidelijk aantonen. Dus het maakt het een veel eenvoudiger routine die je moet doorlopen als het tijd wordt om dat soort dingen waar te maken.
Dez Blanchfield: Eén ding komt bij me op, oh sorry, ga …
Robin Bloor: Het is goed, jij gaat naar Dez, ik wilde een mogelijk irrelevante vraag stellen.
Dez Blanchfield: Gewoon iets heel snel, terwijl je nu bezig bent met het onderwerp waar je nu mee bezig bent - we zien veel meer acceptatie van cloudomgevingen en als we dit in ons eigen datacenter, in onze eigen omgeving uitvoeren, ze kruipen rond en vinden dat het ontdekken van dingen relatief eenvoudig is.
Hoe gaan we om, hoe gaan we om met het scenario waarbij we drie gegevenssets, twee clouds en zichtbaarheid in deze omgevingen hebben, is firewalled en vaak is er een gegevensset aan het einde van een pipe of een VPN. Is er afstand om te ontdekken vanaf de front-end of moeten we, om poorten te openen zodat we in bepaalde omgevingen kunnen scannen tussen een soort cloud en off-premises waar dit platform actief is?
Bullett Manale: Ja, dat zou zo zijn, er zou enige overweging zijn met betrekking tot de poorten. Dus het is, helaas, ik wou dat ik kon zeggen dat het door al die omgevingen gaat breken, maar er zijn een aantal verschillende opties die je hiermee kunt doen. Het is duidelijk dat als je zoiets als Amazon EC2 doet, je alleen echt de toegang tot die omgeving nodig hebt via je connectiviteit, ervan uitgaande dat je poorten open zijn en dan in staat zijn om je IP-adressen of je bijbehorende domein op te geven en het kan beginnen de verzameling en start ontdekking.
Dus het is echt geen probleem in dat soort omgevingen; het zijn de meer specifieke soorten omgevingen zoals RDS en waar je alleen de database zelf krijgt waar het een beetje uitdagender wordt om dat soort informatie te zien en te ontdekken.
Dez Blanchfield: Dus daaruit voortkomend, zijn er databases en databases. Dus bijvoorbeeld de goede oude tijd van het gewoon een heel, heel grote database-engine zoals de anekdote die ik aan de voorkant heb gedeeld, waar het slechts één enorm platform is en alles wat het doet is database bieden. Tegenwoordig zijn databases in alles ingebed, er zijn er zelfs twee of drie in mijn telefoon achter apps.
Wat voor uitdagingen zie je met scenario's waarin je omgevingen hebt die afkomstig zijn van Lotus Notes, met apps erachter, SharePoint met de database op het verschillende internet, enzovoort? In wezen wordt alles aangedreven door een database aan de achterkant. Wat voor soort dingen zie je daar en met wat voor uitdagingen zie je mensen die alleen maar proberen dat soort werelden in kaart te brengen en wat jouw tool voor hen doet?
Bullett Manale: Nou, ik bedoel dat het ding erover is dat wat je zei - alles nu een database nodig heeft, dus vaak zijn er heel veel waarschijnlijk, er zijn veel databases die in de omgeving worden geïntroduceerd die de DBA zelf worden er zelfs niet op gewezen omdat het over het algemeen niet zo moeilijk is om een SQL-server in de omgeving te installeren.
Deze tool identificeert ook dingen zoals express-databases, dus de gratis versies van SQL Server. Grappig genoeg, als je weer met de DBA's gaat praten, krijg je opnieuw geen consistent antwoord in termen van doen ze om de gratis databases die er zijn. Veel van deze toepassingen waarover u spreekt, zullen de gratis versie van de database gebruiken. Maar de organisaties zelf zullen een andere houding hebben in termen van wie verantwoordelijk is voor die database, afhankelijk van met wie je praat.
Sommige DBA's waarmee ik spreek, kan ik denken aan de laatste keer dat ik bij SQL Server PASS was, dat in Seattle is, je de vraag stelt "Geef je om je express-databases?" En het was ongeveer fifty-fifty. Sommige mensen wilden hen als een DBA leren kennen, omdat ze het gevoel hadden dat ze deel uitmaken van hun verantwoordelijkheden, zelfs als die uitgedrukte databases ze nog steeds kritische informatie konden bevatten; ze moeten nog steeds het back-upproces doorlopen en moeten er nog steeds voor zorgen dat alle dingen vanuit een gezondheidsperspectief op hen werken. Maar alleen maar weten dat ze bestaan, is net zo belangrijk, zo niet belangrijker.
Terwijl de andere helft van de mensen zijn: "Hé, we zijn niet verantwoordelijk voor die databases en alles wat ze erop zetten is op hun hoede voor de persoon die ze heeft geïnstalleerd." Maar ik zou zeggen dat in het algemeen wat je gezegd, alles heeft tegenwoordig vrijwel een applicatie die alleen maar bijdraagt aan de complexiteit en de verwarring van het moeten inventariseren van die informatie.
Dez Blanchfield: Ja, ik heb er een paar gezien, overheidssites zijn waarschijnlijk mijn favoriet, maar vaker wel dan niet zie ik nu in bedrijfsomgevingen waar, zoals je zei, dat mensen ik zelfs vergeten, wanneer ze zoiets installeren als SharePoint of zoals zelfuitwisseling, zodat je weet dat ze een gratis versie hebben die gewoon is ingebouwd omdat ze het snel willen installeren en geen zorgen hoeven te maken over het kopen van licenties.
Dan wordt het groot en dan begint iemand te klagen over de prestaties en ze zeggen: "Het is gewoon je oude server, je opslag, je netwerk, wat dan ook, " en dan wordt de DBA gebeld en ze zeggen: "Nou, jij ' heb net alles in deze gratis versie van de database gepropt, wat niet nodig is om deze grote uitvoering uit te voeren. "
In het bijzonder wanneer u scenario's hebt zoals Project Manager en Office worden er honderden, zo niet duizenden projecten uitgevoerd in een grote onderneming of een bedrijf en ze gebruiken SharePoint met Microsoft Project Server en ze dumpen al hun PMO-dingen in deze database. Maar aan de voorkant zijn ze net, het is gewoon een webinterface. Maar er zijn echt databases en databases.
Bullett Manale: Ja.
Dez Blanchfield: Dus wat zijn ze, een van de eerste stappen die mensen hier maken, ik denk dat er een paar vragen zijn die we misschien uit het publiek willen halen. Een van de eerste vragen is waar mensen beginnen? Wat is de eerste natuurlijke stap voor hen om te gaan: "Oké, we moeten de Anonieme versie van Alcoholisten min of meer doen?"
We hebben meer databases dan we weten wat we ermee moeten doen. Wat is een natuurlijk soort stap van hen om te gaan, "Oké, we moeten dit ding krijgen en gaan rennen?" Gaan ze gewoon koud kalkoen of later moeten ze echt klein beginnen en gewoon wat ervaring opdoen over het in kaart brengen van hun omgeving ?
Bullett Manale: Nou, ik denk dat gezegd wordt dat ze de omgeving in kaart moeten brengen. Nu biedt Microsoft een gratis tool om dat te doen, de Microsoft Assessment Planning Tool, het is een gratis tool maar het is statisch. Je doet de ontdekking en dat is het. Je krijgt een lijst van de dingen die er zijn. We hebben dat gedaan en gezegd: laten we een stap verder gaan, laten we de ontdekking doen, laten we kijken wat er is en laten we het in de repository plaatsen en laten we het zo dynamisch maken dat we er iets aan kunnen toevoegen, eruit kunnen verwijderen.
Maar over het algemeen is de grootste eerste stap denk ik gewoon om erachter te komen, de ontdekking te doen. Of het nu gaat om het downloaden van ons product in proefversie, u kunt dit downloaden en 14 dagen uitproberen en u wijzen op uw omgeving en de verzameling doen.
Als u nu al een spreadsheet met een hoop van die informatie hebt en er zeker van bent dat die informatie correct is, kunt u ook de import naar CSV van die spreadsheet met al die informatie leuk vinden en dat deel uitmaken van wat u al hebben. Maar in termen van uitzoeken wat je niet weet, is de enige manier om dat te doen, handmatig uit te gaan, het te doen of een tool te hebben die naar dat soort dingen zoals deze zoekt. Dat is de beslissing die je op een gegeven moment moet maken: "Probeer ik die ontdekking te automatiseren of op zijn minst een goede basis te krijgen van wat er eerst is en me dan misschien zorgen te maken over enkele uitzonderingen?" meestal heb je waarschijnlijk een hulpmiddel nodig.
Dez Blanchfield: Dus gewoon snel. Waar gaan mensen hiermee naartoe? Hebben ze je website geraakt? Hoe kunnen ze hier snel aan de slag gaan?
Bullett Manale: Als je naar Idera, IDERA.com gaat, zul je het zien, en ik kan het eigenlijk gewoon heel snel heel snel laten zien. Ga op de Idera-website naar producten, ga naar voorraadbeheer. Je zult zien dat er hier een downloadlink is. Je bepaalt gewoon welke build je op een 64- of 32-bits wilt installeren, en dat zal je op weg helpen en je kunt vanaf daar beginnen met je ontdekking.
Robin Bloor: Fantastisch en geweldig, geweldige presentatie, heel erg bedankt.
Bullett Manale: Bedankt.
Eric Kavanagh: We hebben een paar vragen van het publiek en we zullen die naar je e-mailen omdat we onszelf vandaag hard moeten stoppen, maar nogmaals, Bullett, geweldig werk op de demo, geweldig werk van onze producent dat het niet zo was ' niet te zien.
Bullett Manale: Sorry daarvoor.
Eric Kavanagh: Nee, dit is goed spul, je geeft inzicht in de kern van het bedrijfsleven, toch? Omdat bedrijven gegevens beheren en u tot in de kern zichtbaarheid geeft. Dus geen hand golvende dingen meer; nu kun je eigenlijk naar dingen wijzen en dat opgelost krijgen. Zo goed voor je.
Bullett Manale: Bedankt.
Robin Bloor: Maar het was geweldig om het trouwens ook live te zien, goed gedaan.
Eric Kavanagh: Ja, we zullen deze webcast archiveren voor later bekijken en dan zullen we het hopelijk binnen ongeveer een uur of twee hebben, het oorspronkelijke archief gaat soms iets langer dan dat, maar we zullen zeker mensen laten weten. Daarmee gaan we je laten gaan, mensen. Nogmaals bedankt voor het bijwonen van de Briefing Room, we zijn eigenlijk de Hot Technologies. We zullen je de volgende keer inhalen. Hou je haaks doei.
