Hämtmat: Värd Eric Kavanagh diskuterar databashantering och instansupptäckt med Robin Bloor, Dez Blanchfield och Bullett Manale i det senaste avsnittet av Hot Technologies.
Du är för närvarande inte inloggad. Logga in eller registrera dig för att se videon.
Eric Kavanagh: Okej, mina damer och herrar. Välkommen tillbaka igen. Jag heter Eric Kavanagh. Det är varmt. Sakerna värms upp här. Jag vet inte vad som händer. Åh det stämmer, det är dags för Hot Technologies. Ja, mitt namn är än en gång Eric Kavanagh. Du hittar mig på @eric_kavanagh. Detta är showen som är utformad för att prata om vad som är varmt på marknaden. Titeln idag, "Keys to the Kingdom: Hantera SQL Server med Dynamic Discovery." Bra grejer. Det är ditt verkligen. Okej, den bilden var från för några år sedan. Jag tänker inte ljuga, jag ser lite äldre ut nu, men det är okej.
Så vi pratar om hur teknologier och SQL Server är riktigt, riktigt, riktigt hett. Vi har en hel massa innehåll idag, så jag ska överlämna det direkt. Stå vid, här går vi. Det finns våra högtalare. Och Robin Bloor går först.
Robin Bloor: Ja verkligen. Presentationen kommer att gå djupare in i databashantering så jag tänkte bara att jag skulle gå igenom databashantering eller, du vet, databaslabyrån, för att få människor till det. Jag brukade vara en DBA, jag antar att du kan säga att jag brukade vara en databankonsult för ungefär 20 år sedan, och det som faktiskt överraskar mig om databaser är att inte mycket har förändrats. Många saker har förändrats med avseende på hastighet, med avseende på datamängderna och sådant, men mycket av det förblir faktiskt mycket likt det som tidigare hänt.
En databas är enligt min mening en organiserad utvidgbar insamling av data som kan optimeras för specifika arbetsbelastningar och leverera kapacitet för datahantering. Det kom främst för att om du ville hantera data i filer var det ett oerhört svårt jobb. Och tanken på att sätta ihop en mjukvara som skulle göra stort sett allt du behöver för att göra, tog nästan omedelbart fart, så snart vi hade slumpmässig åtkomst till IBMs stordatorer på 1970-talet.
Den relationsdatabas uppfanns på 70-talet och kom till i form av prototyper på 80-talet och typ av fick sin dragkraft på marknaden från början av 90-talet och framåt. Och relationsdatabaser är fortfarande helt dominerande i popularitet. Om du läser pressen kommer du att höra en hel del saker som sägs om dessa - SQL-databaser och nyligen finns det mycket hemskt med grafdatabaser. Och de är intressanta, om du vill, men faktiskt fortfarande i de senaste försäljningsnumren, har relationella databaser 95% av marknaden. Och Microsoft SQL Server som vi kommer att diskutera på något djup idag är den näst populäraste för Oracle.
Saken med relationella databaser som gör dem ovanliga när det gäller de motorer som de är är att de kan arbeta på både OLTP och fråga arbetsbelastningar. Du måste ställa in dem annorlunda om du ska göra det men de kan faktiskt ha båda typerna av arbetsbelastning. Den ena är korta slumpmässiga transaktioner och den andra är långa frågor som spänner över mycket data. Alternativet, NoSQL-databasen och grafdatabasen, är främst för analys och de har uppstått ganska nyligen. NoSQL kom först och grafen har börjat få lite dragkraft på senare tid. NoSQL kan användas för transaktionsaktiviteter, men diagram används nästan aldrig för transaktionsaktiviteter. Anledningen, jag stötte på en statistik som jag tror är minst tio år gammal som säger att de flesta företag har minst tre, faktiskt var siffran 3,5, olika märken av databaser, om du tittar på deras programvara.
Men verkligheten är att de flesta företag standardiserar på en specifik databas. Och de flesta företag har standardiserat antingen på SQL Server och Oracle som de två mest populära för, om du vill, standarddatabaser.Och de använder alternativen bara under exceptionella omständigheter där de till exempel får ett mjukvarupaket som behöver en annan databas eller om de följer några av de stora dataanalysmålen som har kommit till.
Vi har också fått, om du vill, störningar från Hadoop. Hadoop har på ett eller annat sätt blivit mer än ett filsystem men ännu inte en databas. Men det har SQL som sitter ovanpå det. Men bevisen där är att det inte riktigt ersätter eller någon annanstans nära att ersätta de relationsdatabaser som förtjänade världens hjärtan och sinnen. Och orsaken till det är verkligen att de relationsdatabaser tog tjugo år, faktiskt längre än tjugo år, för att bli så bra som de är. Och du bygger inte bara en frågeformotor eller SQL-motor som verkligen fungerar på mycket liten tid. Det händer bara inte.
Och så slutsatsen av denna bild är att databaser är strategiska och de utvecklas, de blir bättre. Och det har verkligen varit fallet med Oracle och Microsoft SQL Server. Du kommer förmodligen, några av er ihåg tillbaka till de dagar då databaser först uppstod men jag gjorde det, jag var en pojke då. Den ursprungliga idén var att det skulle finnas en enda databas och det var en konceptuell idé som absolut aldrig slog rot. Det gjorde ett försök från IBM med AS / 400 att faktiskt ha ett databasbaserat filsystem men det dominerade inte heller. Du har kvar det faktum att databaser naturligt fragmenterar. Du har naturligtvis flera instanser. Det finns problem med skalbarhet. Databasen skalas bara till en viss storlek, visserligen har storleken ökat med åren, men de hade gränser.
Och det fanns problem med arbetsbelastningen, den största arbetsbelastningsfrågan var att OLTP-arbetsbelastningar och stora frågeställningar är helt enkelt inte kompatibla med varandra. Och det var omöjligt att bygga en motor som skulle göra det. Vad vi stöter på, vilket är typ av intressant, jag stötte på en webbplats nyligen som hade över tusen olika instanser av Oracle. Jag kommer inte ihåg exakt hur många DBA de hade, men om du faktiskt pratade med dem om hur många av dessa databaser som faktiskt övervakades av en DBA, var det något som tio. De använde i princip databasen som ett skåp och kastade bara data i den eftersom du åtminstone hade ett schema och det var mer organiserat än ett filsystem någonsin skulle vara, men ingen gjorde något annat än att ge det en standardkonfiguration och ställa in det lösa.
Jag är inte säker på om det var en bra idé. Det låter bisarra för mig, för att vara ärlig, för min mening, när jag jobbade med databaser, databaser behövde närvaro och du behövde på ett eller annat sätt veta exakt vad som hände där ute. Och mycket fruktansvärda system beror på att vissa typer av servicenivåer absolut måste uppfyllas, annars får du problem.
Det var samtal nyligen, jag har stött på olika databaser som påstår sig självjustera. De som är kolumnlagrar som är inställda för frågetrafik är i stort sett självinställning eftersom det finns väldigt två val du måste ta när det gäller indexen. Men bortsett från det specifika området måste databaserna stämmas in. Och de måste vara avstämda, vissa relationella databaser, främst för att en fruktansvärd massa transaktioner innebär anslutningar. Skarvar är dyra aktiviteter. Om du inte sätter rätt index på rätt ställe, kommer du att ta överdrivna mängder tid när de inte behöver det.
Självjusterande databaser för närvarande, det finns bara i dessa områden där arbetsbelastningarna är välkända. Och min erfarenhet är att de flesta företag använder mycket få DBA och det beror på att de är dyra. Och därför är det bättre om du kan växla vad DBA gör. Detta är en DBA: s aktiviteter som jag förstår dem. De gör installation, konfiguration och uppgradering av databaser. Uppgradering är förresten inte nödvändigtvis en triviell aktivitet. Anledningen till att du skulle uppgradera en databas, jag menar, regeln som jag alltid har arbetat med är inte att röra den om den fungerar, och om du ska uppgradera en databas till någon ny version, gör du det i testläge först och därefter uppgraderar du allt. Du har fortfarande alltid att göra med samma version. Men faktiskt många webbplatser jag har stött på, det är inte vad som händer. Det finns, låt oss säga, en rättvis grad av entropi. Licenshantering är ett problem, beror på vilken licens du har. ETL och datareplikering.
Ett av knepen med databasen är om du har en arbetsbörda för frågan som måste delas, du kan skapa två instanser och replikera och det görs ofta där människor använder repliken som en säker backup om det behövs. Sedan lagring och kapacitetsplanering, det är en del av en DBA: s aktivitet på grund av att kursdata växer och du måste spåra det. Och sedan måste du planera för olika hårdvaruuppgraderingar eller maskinvaruförstärkningar. Det finns felsökning som är en smärtsam aktivitet för de flesta DBA. Där något går fel och säkerhetskopian inte fungerar exakt perfekt och då måste de rulla upp ärmarna och gå ner och försöka återställa saker från loggfiler. Det händer sätt oftare än jag tror, ja, jag kommer ihåg det som hänt men jag har varit ur spelet i minst tio år, men jag kommer ihåg att det händer sätt oftare än du någonsin hade förväntat dig. Prestationsövervakning och avstämning är bara ett slags hjärta i ett DBA-jobb. Men det finns också säkerhet när det gäller åtkomsthantering, säkerhetskopiering och återställning, vilket skapar testsystem för mjukvara som rimligt parallellt med ett live-system kommer att göra. Och hela datan livscykel grejer. Så det är enligt min mening DBA: s lista över jobb bortsett från allt annat som de kan bli ombedda att göra. Operativ dynamik. I slutändan är dataintegritet och hantering av servicenivå DBAs huvudansvar. Och normalt sett är de kritiska. Och det är allt jag har att säga. Jag ska överlämna till Dez.
Dez Blanchfield: Tack så mycket. Jag kommer att ta oss med på en lite rolig, anekdotisk resa runt varför hela ämnet som idag handlar om och är mer kritiskt än någonsin. För inte så länge sedan deltog jag i ett projekt där vi migrerade en statlig plattform som användes för licensregistrering och fordonsregistrering och en hel rad saker kring det ämnet, från en Fujitsu mainframe-plattform som körde en sak som heter A + Addition, som är ett Solaris-operativsystem, eller med andra ord, Unix, kör Oracle och gör ett mycket bra jobb med det. Och uppfattningen var att den här saken blev gammal och det var dags att flytta den till något annat. Vi hade mycket kul att köra Unix på mainframe och det var väldigt stabilt och väldigt säkert och konstigt nog SDL-plattformen och det var bara helt snabbt. Men visdom var att det var dags att gå ur stordatorn och flytta.
Denna betydande utmaning att kartlägga alla system och affärslogik och SQL-miljön för databaserna under och titta på hur vi skulle arkitektera och konstruera ett nytt hem för det. Och vi slutade med att ta den till en av de här sakerna som är ett par år gammal nu, men en av de översta ändarna på Sun-racksystemet Starfire-servrar. Och det är förmodligen något av det största tennet du kan köpa på planeten som alla lever i en stor låda och en symmetrisk multiprosessionsserver. Det var ett mellanklasssystem i vår värld. Det körde Unix och det sprang Oracle infödda och utsikten var: "Vad kan möjligen gå fel?" Det visar sig mycket.
Till exempel vid den tiden, och vi inte talar om för länge sedan, var vi tvungna att gå igenom en mycket manuell process för att upptäcka vad som fanns på mainframe-plattformen och föra över. I synnerhet den faktiska databasmiljön och SQL-logiken. Så vyn var att det skulle bli ett ganska enkelt Oracle-to-Oracle-drag, databas-till-databas-drag; all affärslogik skulle komma över, det mesta av affärslogiken hade skrivits i inbäddade frågor och triggers, och hur svårt kunde det vara? Men något som var tänkt att ta månader slutade med att inte ta ett helt år. Att bara fysiskt och manuellt gå igenom alla delar av Unix på stordatormiljön, upptäcka var alla databaser var och hur många instanser som kördes och vad som kördes på dessa instanser och det var en icke-trivial övning och vi slutade med att göra det tre gånger bara för att se till att vi hade fångat allt. För varje gång vi trodde att vi hade grävt så djupt som vi behövde, under ytan visade det sig att det var mer där.
Den andra utmaningen vi hade var vilka instanser som körs och i vilket tillstånd? Är detta en utvecklingsmiljö? Är det en testmiljö? Är det en del av integrationsprocessen? Är det systemintegration? Är det UAT, användarens acceptans testning? Är det produktion? Är det en DR-miljö? Eftersom det fantastiska med mainframes är att du kan bygga dessa lilla virtuella miljöer som vi alla tar för givet nu och flytta saker runt. Och du måste träna är den här personen som utvecklar och testar produktionskvalitet, eller gör de produktionsproduktion, finns det faktiska användare på det här? Kom ihåg att denna sak gör i realtid utfärdande av körkort och bilregistrering och saker som verkligen betyder för människors liv.
Och det tog lång tid att köra säkerhetskopior för den här saken så att vi inte riktigt hade ett fönster för underhåll för att ta saken offline och se vad som hände. Det fanns inget sådant som att omdirigera det. Vi hade också utmaningen att inte bara hitta vilka instanser som körs och var och vem för, men sedan var vi tvungna att ta reda på vilka versioner av vilka instanser som kördes. Och det är där jag nästan tappade min tomt. När jag började inse att vi hade två eller tre versioner av produktionsmiljön genom olika testnivåer och det fanns väldigt lite i vägen för verktyg och systematiska metoder för detta. Vi var bokstavligen tvungna att fördjupa koden och i den löpande instansen och i vissa fall ta risken att ta något offline en liten stund. Vi kom till botten av hela det här, vi kartlade det och det var en mycket manuell process som sagt. Och vi gjorde slutligen hela ETL-skiftet, dumpade det från ett ställe och flyttade det till ett annat och i det hela taget fungerade det. Och vi var som, okej det är funktionellt, vi är väldigt nöjda med det.
Men sedan stötte vi på ett antal mycket allvarliga massiva tegelväggar. Vi hittade särskilt prestationsproblem. Och dagens förnuftiga tänkande var, det har gått till en större, bättre, snabbare och hårdare hårdvara, det finns ingen anledning till varför den skulle fungera dåligt på applikationen på databasnivå, så låt oss börja leta någon annanstans. Så vi ombyggde nätverket två gånger. Varje router, varje switch, varje kabel, vi gick från Ethernet till fiber i vissa fall, vi uppgraderade programvara, vi lappade, du får vyn. Vi byggde i grund och botten nätverket två gånger och tänkte att det var prestandafrågor där. Och det såg ut och kändes som det var. Vi gick igenom olika säkerhetssystem, olika brandväggar. Vi lappade operativsystemet. Vi flyttade saker från ett datorblad till ett annat. Och vi tillbringade en betydande tid på att titta på infrastrukturen.
Och då insåg vi att när vi kopplade bort servrarna och körde några andra applikationer på det så fungerade nätverket helt fint. Så vi började dra isär operativsystemet. Samma nummer. Men intressant, nätverksnivån och operativsystemnivån, verktygen var där, det var faktiskt relativt enkelt för oss att benchmarka och testa och bevisa att var och en av dessa bitar fungerade. Men även då, på Solaris på mellanklass på SPARC hårdvaruplattform, var verktygen bara inte där för att vi skulle kunna börja diagnostisera databasmiljön. Du vet, kartlägga huruvida vi har kommit över alla instanser. Och så var vi tvungna att bygga våra egna verktyg och skriva några och sitta ner, oavsett om det var i databasverktygen själva på de ursprungliga skriptspråken eller om det var en serie skalskript eller i vissa fall ett gäng C-program.
Vi delade till slut in några mycket intressanta problem där logiken under SQL-lagret, själva databasmotorerna, visade sig att när något byggdes ett särskilt sätt för något som körde på mainframe-versionen av Oracle migrerades till Solaris på SPARC version Oracle det transponerade inte omedelbart samma prestanda. Så detta var en ganska smärtsam resa för oss i första hand, bara göra det och hitta allt, men nu var vi tvungna att diagnostisera det i det nya produktionssystemet och igen blåste denna sak ut en månads migrationsvärde till nästan ett år. Och det kom helt enkelt ner på att vi inte hade verktygen runt. Kör runt och gör saker som att försöka kartlägga metadata.
Vid någon tidpunkt beslutade vi nästan att vi behövde ett Ouija-bräde eftersom det skulle bli lättare på det sättet att bara slumpmässigt peka och pirka. Enkla saker som att ta reda på vem som hade tillgång till de gamla systemen och varför de hade den åtkomsten. Och som behövde åtkomst till den nya och bekräfta, få någon att logga ut och bekräfta det och kartlägga det. Till och med något så enkelt som databasens storlek var inte konsekvent på de två plattformarna. Vi var tvungna att bygga ett verktyg för att göra det och göra en jämförelse mellan hur stor databasen är i tonnage, i råa megabyte eller terabyte på System A kontra System B. Och dykning mer detaljerat kring prestanda och den performanta miljön. Återigen, var tvungen att bygga nya verktyg. Det fanns bara ingen hylla för oss.
Och du får allt detta, när vi slutade med att få saken igång och vi fick det stabilt, varenda bit av det var en mycket manuell process, det enda sättet vi kunde automatisera något på var om vi bygger en ny verktyg eller nytt skript. Och om vi hade de verktyg som finns tillgängliga idag, skulle livet ha varit så mycket lättare och så mycket bättre. Och vi skulle ha sparat miljoner på detta projekt. Men jag tror att det vi ska prata om idag är det faktum att verktygen finns tillgängliga nu och de gör livet så mycket lättare. Det finns fortfarande många fallgropar. Upptäckt av databaser som finns ute och vilka instanser som kör vad. Vilket läge är de i. Hur många körs? Varför de springer. Oavsett om de kör bra. Säkerhetskopieras de?
Det här är allt som vi på många sätt kan ta för givet nu med rätt verktyg. Men det fanns en period i just denna anekdot som jag sa, där det var något som många av oss tappade mycket hår om, vi tog förmodligen femton år av våra liv och beklagar det faktum att verktygen inte fanns där nu . Och jag ser fram emot att höra mycket mer om det från vår gäst idag, Bullett. Så med det, Bullett, ska jag skicka till dig och jag ser fram emot att höra hur du har löst det här problemet.
Bullett Manale: OK. Låter bra. Eric, låt mig ta över här med bilderna och prata lite om, verkligen snabbt, Idera, företaget, innan vi går in i själva produkten. Precis som ett FYI är detta en sort av en portfölj av olika produkter som vi har tillgängliga.
Eric Kavanagh: Ditt ljud är lite hett, så om du använder ett headset bara dra det upp lite.
Bullett Manale: Inga problem. Är det bättre?
Eric Kavanagh: Det är mycket bättre. Ta bort det.
Bullett Manale: OK. Så idag kommer vi att fokusera på Inventory Manager som uppenbarligen är anpassad till många av dessa ämnen som vi diskuterar. Jag vill bara ge er lite förståelse för hur den här produkten kom där den är. Vi började se ut på en daglig basis med vår produktlinje, vi har ett prestationsövervakningsverktyg som heter Diagnostic Manager. Vi har ett Compliance Manager-verktyg. Så många olika verktyg runt SQL Server och oundvikligen ställer vi alltid frågan för licensändamål, "Hur är antalet instanser som du för närvarande hanterar inom din organisation?" Och det intressanta var att vi aldrig kunde få ett fast svar på det. Det spelade ingen roll vem du pratade med. Det var alltid så, "Vi tror att det är runt det här numret." Sådana saker kom alltid in och då skulle vi behöva gå igenom denna process för att ta reda på exakt vad det var som de hade som de ville licensiera i de fall vi hanterar.
Vi har naturligtvis räknat ut riktigt snabbt att det verkar finnas en del smärta i samband med det med många DBA. Uppenbarligen som DBA är en av de saker de ansvarar för att veta att eftersom en av de saker de måste göra är att oroa sig för sina licensavtal, i vårt fall med Microsoft och SQL Server. Uppenbarligen har de många andra olika områden som de ansvarar för, men det är en av de som är typ av en stor biljettartikel när det gäller DBA vad ditt allmänna ansvar är. Med det vi drog slutsatsen av är att vi behöver ett verktyg som gör det enkelt för en DBA att verkligen kunna förstå det numret. Eftersom du har SQL-spridning om du vill kalla det så och det händer av flera olika skäl. Det finns inte så mycket kontroll över vem som installerar programvaran och den typen av saker.
Och det värsta som kan hända är att någon tar hand på en kopia av SQL Server, installerar den, börjar arbeta med den utan någon kunskap till några av de andra organisationerna eller avdelningarna i företaget, och sedan är det nästa du vet, kanske data säkerhetskopieras inte, och sådana saker som kan hända. Där nu har du ett annat problem, där du har situationer där du faktiskt kommer att förlora kritisk data eftersom du inte vet att instansen till och med existerar i första hand.
En av de saker som vi var tvungna att göra var att säga låt oss ta reda på upptäcktsdelen av det. Och sedan dessutom kunna organisera och hantera den information som vi samlar in på ett logiskt sätt som är vettigt baserat på vad verksamheten gör. Och sedan självklart att kunna fatta beslut kring den informationen och kunna göra sådana saker. Det är typ där verktyget startade och var det kom ifrån. Jag kan säga er att när vi pratar med DBA regelbundet, det vi egentligen har är det problemet att inte veta hur många fall de har.
Och det är roligt eftersom termen, du kan inte hantera det du inte kan mäta, alltid kom med prestationsverktyg som vi har, som SQL Diagnostic Manager, men du kan verkligen inte hantera någonting om du inte vet det "Dess" till och med där i första hand. Så det är också en stor del av det här verktyget att kunna veta att det finns där.
Nu på den noten, att prata med några av de större organisationerna eller företagsbutikerna med SQL Server, det intressanta som vi hittade med många killar som vi pratade med var att de faktiskt hade satt upp en tid under deras år där de gick faktiskt fysiskt från en plats till en annan för att försöka bestämma hur det räknet ser ut. Du kan föreställa dig som DBA att du får en ganska bra summa för att fysiskt gå från en maskin till en annan i vissa fall, vilket var förvånansvärt vad vi skulle höra från några ganska stora företag som jag inte kommer att namnge. Men en typ av intressant punkt som två veckor om året kan ägna sig åt att göra sådana övningar bara för att ta reda på om deras licensräkning är korrekt.
Det här är allt relaterat till det här verktyget och hur det hjälper men det sätt vi behandlade det var genom förmågan att upptäcka baserat på ett antal egenskaper hos SQL Server. Och så är den första frågan, vad pekar du på eller vad försöker du titta på först? Så vi gjorde det var att säga låt oss göra det via IP-intervallet eller så kan vi göra det genom medlemskapet i själva domänen när det gäller datorer som är medlemmar i domänen. Det är på det sättet vi behandlade den delen, bara för att kunna säga att detta är det område som vi vill fokusera på när det gäller upptäckten.
Och sedan den andra delen av det är baserat på de egenskaperna, portarna och andra saker, WMI-registernycklar och den typen av saker, vi kan samla och kontrollera att SQL troligen körs och installeras i den instansen eller den specifika miljön. Det är uppenbarligen en mycket bättre metod än sneakermetoden eller sneaker expressmetoden. Nu är det coola att all den information som vi samlar om instansen förvaras i ett förvar och den kan förändras när miljön förändras. Det handlar inte bara om, "Hej, det finns en instans, här är en lista som vi hittade," utan det är som DBA, eller personen som hanterar förekomsten, att kunna avgöra om de vill göra den delen av inventeringen, och sedan när det är inte en del av inventeringen, för att kunna ta bort den instansen. Och så har de livscykeln för hela processen i SQL Server-instansen att verkligen lätt förstås i verktyget.
När vi har upptäckt fallen, vad gör vi efter det? Det andra är mycket information om instansen, jag vill inte behöva manuellt skaffa den och lägga den i ett kalkylblad eller sådana saker. Och det är en annan sak som var ganska intressant när jag pratade med DBA om inventeringsprocessen och licensieringen, är att du skulle bli förvånad över hur många DBA som jag talade med, när du frågar dem, "Hur underhåller du dina varulager?" Och vi pratar med DBA som är den riktigt ironiska delen av det, att de håller det och spårar det i ett statiskt kalkylblad med alla saker. Som jag sa, det är väldigt ironiskt när du tänker på det en minut. Men det var i många fall, och det är fortfarande fallet med många organisationer hur de hanterar det. Hur de håller det. Det är en masterkopia av ett Excel-kalkylblad som flyter runt och det måste uppdateras regelbundet.
Det är saker som var en utmaning och så genom att registrera instansen och göra den till en del av inventeringen kan du göra det och hämta informationen. Du kan låta den automatisera huruvida den blir en del av inventeringen, versionen, upplagan, andra saker du kan göra med det är att du manuellt kan lägga till den listan eller Excel-kalkylbladet som du har. Du kan importera det till det här verktyget som heter SQL Inventory Manager. Om du redan har en utgångspunkt för instanser som du känner att du är ganska säker på kan du importera dessa instanser i och sedan göra den delen av ditt hanterade lager i produkten. När vi har fått instansen och när vi väl vet att den är där så blir den, okej, vi har mycket information som vi kan utnyttja genom att veta att den instansen finns där, genom att gå ut och samla in den informationen.
Och mycket av informationen kommer att behövas för mer än bara licensiering. Mycket av det kan användas för att uppenbarligen bara veta var saker är, för att kunna söka igenom denna information efter att den har erhållits. Men de viktigaste sakerna är servern, själva hårdvaran. Att kunna förstå vilken typ av maskin det är, kanske modellen eller tillverkaren, minne, mängden minne, om det är en fysisk eller virtuell maskin och särskilt antalet fysiska uttag eller kärnor och CPU och sådana saker.
När det gäller antalet kärnor, speciellt med SQL Server, att veta hur de gör deras licensiering är kärnberäkningar nu i de nyare versionerna av SQL, som blir en riktigt viktig del av det och det är inte något du har att gå ut och faktiskt gå gräva efter. När instansen har identifierats kan vi ge den informationen och få den ut och låta dig se den och förstå den och uppenbarligen kan dra nytta av den.
Nästa skikt nedåt är i det fallet som du uppenbarligen har mycket olika av SQL Server-instansen oavsett om det är standard eller företag eller till och med express för den delen, eller den gratis versionen av SQL Server. Att kunna förstå även vilka applikationer som är kopplade till den instansen och detta kan göras automatiskt. Att kunna förstå konfigurationsinställningarna och den typen av saker samt annan information som är relaterad till förekomsten av själva SQL Server.
Då kommer du ner till själva databasen och ser konfigurationsinställningarna, hur mycket utrymme som är bundet till den informationen, där den ligger, allt detta fylls automatiskt och det är en enorm tidsbesparing. Och än en gång, eftersom det dynamiskt går ut och dagligen identifierar nya instanser, är det en levande sak som du har när det gäller ditt lager. Det är typ av produktens mål att göra det på det sättet, är att göra det till något som förändras dynamiskt.
När all denna information nu blir tillgänglig för oss och vi kan dra in all denna information, är det verkligen vettigt att i vissa fall börja skapa dina egna metadata kopplade till dessa instanser och att metadata kan skapas på ett sådant sätt anpassar sig till det sätt du gör affärer på.
Så om du har dina instanser grupperade efter geografisk plats, eller av applikationsägare eller av DBA-ägare eller vad som helst, kan det vara i termer av hur du vill gruppera dessa instanser, hur du logiskt vill förstå dessa instanser, så är det av två områden i verktyget som ger dig den möjligheten.
Den första är förmågan att skapa en instans-tagg eller en tagg. Vilket är i huvudsak att skapa en associering till antingen servern, instansen eller databasen så att du kan skapa vyer och svara på frågor som kan komma upp på en daglig basis, som verkligen hjälper dig att ta hand om vad du har, vad du hanterar och hur du vill gå vidare med den informationen.
Det andra som vi har är något som kallas inventeringsfält eller anpassade inventeringsfält och dessa är mer specifika för typ av små information som du kan borra i, till exempel databasskiktet jag kanske beslutar att lägga till en listruta som har alla DBA och jag kan sätta vilka som är ansvariga för den databasen beroende på vilken typ av situation eller vad som helst, vilken databas det är med vem som är ansvariga för den att kunna välja det så att jag vet att de är de som är ansvariga och mycket enkelt bara genom att gräva i inventeringen.
Så dessa informationsmaterial blir mycket värdefulla, särskilt om du har en stor miljö, eftersom det bara hjälper dig att känna till den informationen och veta vad du har och hur du gör det.
Så låt mig gå vidare och byta till nästa bild här. Det jag visar dig nu är att all denna information samlades in, all denna information och data som samlade in och använde metadata för att ge dig möjlighet att sedan göra mycket enklare och snabbare beslut när det gäller att visa upp dina licenser hos Microsoft i företagets volymlicens eller programvaruförsäkring hos Microsoft.
Det gör det verkligen enkelt för dig att göra detta snarare än att behöva, behöva gå och göra mycket manuell insamling av data, mycket manuell insamling av den informationen som egentligen bara totalt sett gör det mycket bättre för en process. Så det är sorts ett av produktens mandat, någon gång för att göra det lättare för DBA att fatta dessa beslut kring licensiering.
Den andra saken som vi, prata med DBA, upptäckte och lärt oss verkligen snabbt är att - och dess typ av att gå tillbaka till det som diskuterades tidigare - du kanske har 300 instanser i din miljö av SQL Server men det finns egentligen bara en delmängd av de som verkligen övervakas och förvaltas helt från en traditionell typ av verktyg för övervakning av prestanda.
Så om du går och du faktiskt sätter dig ner med DBA och du säger: "Se, vi vet att du har fått dessa 20 instanser eller 10 instanser av de 300 som övervakas med det här verktyget som är utformat för att övervaka det och överensstämma med dina SOA och få varningar och alla sådana goda saker, ”vad vi också hittade är att om du frågade,” Vad är det då med de andra 280 instanser du har? Bryr du dig om dem? ”Och de gör, de bryr sig om dem, men de vill bara inte nödvändigtvis göra en investering för att övervaka de på den djupnivå som kan göras med dessa instanser kontra de 10 eller 20 riktigt, riktigt kritiska produktinstanser.
Så den andra delen av ekvationen med detta verktyg är att det också hjälper när det gäller att kunna se till att du på en basnivå är täckt när det gäller instansens hälsa. Nu kommer det inte att berätta om du har ett dödläge eller vem offret för dödlåset är. Det är inte att komma till den nivån på själva sessionerna och detaljerna i frågorna. Men samtidigt kommer det fortfarande att låta dig veta att hej servrarna eller hej volymen fyller eller så måste du göra säkerhetskopior av databasen, det är en viktig del av att vara en DBA.
Så den typen av saker är definitivt fortfarande viktigt och så med detta verktyg slags gjorde det ett sätt för dig att ha en fånga allt för dina riktigt kritiska instanser som har mycket, mycket värt bundet till dem, om de går ner måste du veta direkt. De kan ha den högre nivån av övervakning och kunna göra sådana saker, medan det med detta kommer att kunna ta upp alla nya instanser som läggs till miljön och se till att de redovisas och också se till att de grundläggande nivåer av hälsokontroller bildas.
Så det är typiskt i ett nötskal vad Inventory SQL Import Managers handlar om. Nu ska jag visa dig en demonstration av det. Innan vi gör det, bara snabbt så visar jag dig att det här är arkitekturbilden här och bara för att visa detta, förekomsten av SQL som hanterade, vi kan upptäcka allt från SQL 2000 hela vägen upp till de nya versionerna av SQL.
Så vi kan göra det utan att behöva distribuera agenter i själva instanserna. Vi gör det genom en insamlingstjänst och det kommer att gå ut och samla in den informationen och lägga den i ett arkiv och sedan från en Tomcat-webbtjänstkonsol och sedan kunna interagera med den informationen och visa den. Så det är ganska enkelt arkitektur.
Jag ska gå vidare och byta över och faktiskt ta oss in i själva produkten så att du kan få en känsla för den, en förståelse för hur den fungerar. Så det bästa sättet att göra detta är att första typen att presentera dig för själva gränssnittet i det här är en slags instrumentpanel som tittade på här.
Jag kan se antalet fall just nu som jag har under ledning är inte riktigt så många. Men jag har inte heller ett helt datacenter i min bakficka. Så Ive har ungefär sex fall som vi ser här. Som sagt: Im, vad jag ska göra är att gå igenom upptäcktsprocessen och visa hur det skulle fungera.
Nu är det första du skulle göra i administrationsavsnittet du kan ange hur du vill upptäcka dina instanser. Du skulle kunna lägga in den informationen här och än en gång som kan göras genom en rad IP-adresser. Du kan peka på en domän eller ett underdomän och bara kunna på de maskiner som är medlemmar i den domänen kunna utföra de kontroller du skulle kunna välja ett antal olika typer av egenskaper när SQL körs för att leta efter.
Sedan när du har gjort det och du kan få det automatiserat att köra dagligen för att samla in dessa data. Du skulle också kunna göra det på ad hoc-basis om det behövs. Men när du börjar det, den upptäcktsprocessen, vad du börjar se är när du går över till instansvyn här. Du har en flik Upptäck och fliken Upptäck kommer att visa oss de fall som nyligen har upptäckts. Så i vårt fall har vi ett nummer här. Vad jag ska gå vidare och göra är att gå vidare och lägga till den som skulle använda som exempel. Så detta är en Chicago-instans i det här fallet, eller hur? Jag ska gå vidare och lägga till den instansen i min inventering.
Okej och det kommer att gå mig igenom ett par saker här. Jag ska bara gå vidare så ser du att vi kan ställa in referenser. Mina referenser borde vara bra där. Jag kommer att gå vidare och du kommer att märka att jag kan tilldela ägande till detta om jag vill. Jag kan också ange en plats. Nu kan själva läget läggas till, och det kommer ihåg att nästa gång, uppenbarligen.
Återigen kan jag också associera taggar till detta i fråga om metadata och hur vi vill placera dessa instanser av SQL, särskilt den här, i vilka skopor vi vill lägga in det. Så vi har några aktuella taggar, populära taggar , så vi kan titta på ett gäng olika taggar som jag kanske redan har inkluderat. Jag ska bara välja några av dessa slumpmässigt och vi kan tillämpa det.
Så nu när jag går vidare och lägger till detta i inventeringen. Nu när det har lagts till skulle vi nu se det dyka upp under den hanterade vyn och så kan du se den listad här. Så du vet att det första steget och vad jag just visade dig var det sätt som du huvudsakligen skulle lägga till dessa instanser när du går igenom dag till dag. I vissa fall kan du säga att du vet vad om det är en företagsutgåva av SQL-server jag automatiskt vill lägga till det i mitt lager? Jag behöver inte manuellt gå och välja att göra det.
Jocelyn: Jag kommer att avbryta dig riktigt snabbt. Såg du inte din demo.
Bullett Manale: Du är inte?
Jocelyn: Nej.
Bullett Manale: Det är inte bra, låt oss se.
Eric Kavanagh: Om du går till det övre vänstra hörnet klickar du på start, klickar på det.
Bullett Manale: Ah okej.
Eric Kavanagh: Och nu dela skärmen.
Bullett Manale: Förlåt för det. Japp.
Eric Kavanagh: Det är okej. Bra fångst där, producent Jocelyn.
Bullett Manale: Okej så är det bättre? Ser du det nu?
Robin Bloor: Ja verkligen.
Bullett Manale: Okej, så låter oss bara ta dig igenom där vi var riktigt snabbt. Vi har upptäckt de fall som vi har haft tidigare. Jag har precis lagt till Chicago-instansen, och det du ser nu är att det nu är listat här. Lägg märke till att det redan har fått mycket mer information. Om jag klickar på själva instansen börjar du se alla typer av information som vi redan har samlat om den instansen. Här är en lista över alla databaser som finns där. Vi kan se en uppdelning av databaserna efter storlek och efter aktivitet i termer av vilka som har det mesta av en storlek och aktivitet.
Återigen kan vi också berätta för dig precis utanför fladdermallen vilka applikationer vi ser kör på den instansen baserat på den arbetsbelastning som vi ser körs på instansen. Så det är trevligt att kunna göra det automatiskt. Jag behöver inte gå in och binda ansökan till förekomsten. Baserat på vad vi såg kan vi fylla det. Om du nu vill lägga till ett program manuellt kan du göra det. Men det är bara ett trevligt sätt att kunna visa föreningens instans till databasen eller, jag är ledsen, till applikationen.
Du kommer också att märka att på höger sida av skärmen har vi en omedelbar sammanfattning och under den har vi en serveröversikt. Så talade vi om vid instansen viktiga informationer här, veta versionen och inte bara, du vet, SQL Server 2012 utan det faktiska versionnumret som, inklusive och berätta för oss vilka snabbkorrigeringar som är bundna till den, vilka servicepaket som är bundna för det kan det vara mycket viktigt att veta. Det är uppenbart att minneskravet är viktigt. Allt sådant, oavsett om det är grupperat, all denna information, jag behöver inte lägga in den - den har redan samlats och samlats in, och när vi identifierar att det är en upptäckt instans, det kommer att vara en del av vårt lager.
Det andra du ser här - och det kommer att visa dig - det är under denna instansvy. Vi har dessa attribut som jag talade om tidigare, de anpassade attributen som kan läggas till. Så vi kan lägga till öppna slags rutfält, vi kan göra ja / nej när det gäller, du vet, en miljard typer av val. Vi kan till och med göra rullgardinslistor. Du kan göra det vid förekomsten av databasen eller på servernivå.
Om vi sedan rullar ner lite längre kan vi se all relaterad information till själva servern. Så du vet att alla sådana saker är uppenbarligen verkligen, verkligen användbara eftersom allt är samlat och samlat och det finns för oss så snart vi fattar det beslutet att göra det till en del av vårt lager. Här kan vi visa några av skillnaderna vad gäller CPU: er, antalet logiska kontra fysiska, hur mycket minne. Så att du verkligen får en riktigt bra och rikedom av information utan att behöva göra mycket arbete.
Nu är den andra delen av detta, som jag sa, att samla in dessa data vid servernivån. Om vi till och med går ner till databasen kan vi se att mycket av det här är uppdelat för oss också.Så om jag går till mitt efterlevnadsförvar, i det här fallet skulle jag kunna säga, du vet att det handlar om en, detta är en databas för överensstämmelse i vilken nivå av överensstämmelse eller myndighetskrav den är kopplad till och det kan vara SOX-överensstämmelse eller PCI-överensstämmelse. Så jag kan välja vilka databaser som har vilken överensstämmelse som är kopplad till dem som jag måste fylla eller se till att jag upprätthåller i enlighet med det lagkravet.
Så den här typen av saker har visat sig vara till stor hjälp för DBA eftersom det är en plats som de kan centralt gå för att hålla alla dessa tillhörande metadata i sin miljö enkelt och de kan göra att de, som sagt, överensstämmer med deras affärer som de gör , som det sättet de gör affärer på. Så om vi hittar alla saker hittills vad vi har sett, har du uppenbarligen en ganska bra översikt över instansen, om jag borrar in i det.
Jag kan också söka också så jag sa låt oss leta efter det efterlevnadsförvaret i mitt lager. Vad du ser här är att jag kan söka efter dessa saker och kunna identifiera dem. Jag säger det - Jag är inte säker på vad, min go-knappar fungerar inte där. Okej. Låt oss se, låt oss försöka det igen. Där går vi. Så vi skulle då kunna se en uppdelning av var vi ser någonting med var överensstämmelse i och jag kan borta ner i det och se det också ur den synvinkel. Så du fick ett riktigt snabbt och enkelt sätt att gräva in denna information.
Nu som vi nämnde tidigare har du många olika sätt att skapa metadata mot instansservern och databasen. Den andra delen av det är att kunna dra fördel av det på det sätt du har grupperat det och på det sättet du har kopplat till det. Vi går till utforskaren, vi kan göra just det. Vi kan säga att jag vill göra en databasräkning efter platser. Så antalet databaser på varje plats i de miljöer som jag stöder. Eller kanske det är baserat på ägaren som äger de instanser som jag har där ute när det gäller kanske instansräkning. Så vi kommer att kunna se det. Så du får ett riktigt bra, enkelt sätt att måla dessa bilder för dig baserat på vilken fråga det är som du försöker besvara vid den tiden.
Sedan vad du har den typen av information skapade som du ville, kan vi exportera den till PDF eller olika format för att kunna utnyttja den och till våra kollegor eller göra vad vi behöver där. Så du vet att du skulle kunna göra sådana saker. Låt oss gå tillbaka till - tappade jag det? Där går vi. Okej, så förhoppningsvis är det meningsfullt vad gäller vad jag har pratat om hittills. Nu när de uppgifter som vi har samlat in är allt detta uppenbarligen mycket viktigt av ett antal skäl - licensiering och vad inte.
Den sista typen av att bara nämna är att vi går över till det här administrationsavsnittet här. Här kan du också konfigurera din och din varning och kunna se till att för de saker som du verkligen vill veta om, kan du också ställa in dessa saker. Så vi kan ställa in varningar, vi kan ställa in förmågan att aktivera vissa saker och stänga av vissa saker och sedan kunna bestämma vem som ska få dessa s, och prenumerera på de varningar vi kan associera vem vi vill vara, som skulle vilja veta om den typen av saker.
Men som jag sa tidigare, det här är ett riktigt trevligt sätt att göra, åtminstone ha en total trygghet för att veta för hela företagets SQL-instanser - vad det är som du har och också se till att det körs optimalt även om du inte gör det, havent fattade beslutet att göra en investering för ett tungt träffande prestationsövervakningsverktyg för att hantera den instansen. Detta kommer att täcka dig eftersom det är ett mycket prisvärt sätt att gå ut och i många fall kunna göra dessa inventeringar och kunna göra en typ av en mycket bred typ av allmän nivå för övervakning för att se till att du fick den sinnesfrid och vet vad som händer.
Så förhoppningsvis är det meningsfullt på det sätt vi har beskrivit det och visat det för dig. Jag antar att från det synvinkeln kan jag gå vidare och skicka tillbaka det och vi kan prata lite mer.
Eric Kavanagh: Det låter bra. Så Robin? Dez? Några frågor?
Robin Bloor: Tja, jag har frågor. Det är väldigt intressant att faktiskt titta på detta, jag menar att jag bara ville göra den kommentar som ganska mycket var överallt jag har varit, inte bara bland DBA, men bland nätverksgubbarna, bland lagringsgubbarna, bland de virtuella maskinhanterings killarna, de är alla arbetar med kalkylblad.
Eric Kavanagh: Det är rätt.
Dez Blanchfield: Du vet typ att det är, du vet att det är okej tills siffrorna börjar röra sig. När siffrorna börjar röra sig, vet du att de kommer att få problem. Så frågan nu är jag ganska intresserad av och jag vet att det kommer att bli svårt för dig att svara, men vad, om du går in på en plats där de inte har något liknande här där för att arbeta med kalkylark, så låt oss anta DBA: er är väldigt smarta killar och så vidare, så vilken ROI tror du att du skulle få genom att genomföra något liknande? Har du några siffror om det på eller några riktlinjer för det?
Bullett Manale: Det är svårt att säga vad ROI är eftersom miljöer kommer att bli lite annorlunda. Uppenbarligen att ju större företag, desto större miljö, naturligtvis desto mer kommer ROI förmodligen att vara om de använder, du vet, manuella metoder nu.
Jag vet att jag har pratat med ett antal - när jag säger stora organisationer i tusentals anställda och förmodligen tusentals instanser också - där jag har människor där jag visar det för dem och de säger att det kommer att ta två veckor av min tid tillbaka. Jag har sagt det till mig mer än en gång. Så det är svårt att säga när det gäller det faktiska dollarbeloppet från ett köp, men det är betydande när du har miljöerna.
Som jag sa, det är ganska konsekvent, det är de människor jag, de flesta människor jag pratar med förvarar det här i ett kalkylblad. Så det är bara en mycket, mycket subjektiv sak eftersom alla miljöer, det är lite annorlunda vad gäller hur de gör sin licensiering och hur de gör sin licensiering med Microsoft är en annan del av det som är en faktor. Men om de måste göra sanna ups varje år eller vart tredje år, jag tror att tre år på max för Microsoft att de kommer, de vill att du ska sanna minst vart tredje år.
Då vet du att det är betydande och det, du vet att det bara är något som underlättar mycket. Eftersom det är en dynamisk sak som alltid förändras, ger det lite mer giltighet också när det gäller vad det är du tittar på verser, väl har vi inte uppdaterat kalkylbladet på sex månader eller ett år. Så hur ofta uppdaterar du kalkylbladet är en annan fråga för att förstå att svaret på ROI.
Dez Blanchfield: Ja, jag menar, SQL-licensiering, licensiering av detta är bara en jävla mardröm, men det är särskilt en mardröm eftersom licensiering inte är densamma mellan Microsoft och Oracle och någon annan som är ute och gör databas saker. Om du faktiskt håller saker i kalkylblad som tenderar att vara vad som faktiskt händer, vet du att licenstid kommer runt innan du faktiskt inser det och du har faktiskt inte uppgifterna, om du vet vad jag menar, för att enkelt få informationen.
Hur som helst, som ni påpekar, det är dynamiskt och jag har ingen aning om personligen, för jag har faktiskt aldrig behövt förhandla med Microsoft, så jag har ingen aning men förmodligen finns det databaser som människor ganska ofta tar ner testdata, testmiljöer och jag skulle gissa att de är en torn i din sida om du gör licensiering. Är det du-?
Bullett Manale: Ja, ja. Det är så eftersom många gånger att saker glömts bort och sedan börjar vi försöka räkna, okej, okej, vi har kärnlicenser som vi måste räkna ut antalet kärnor för var och en av dessa instanser och jag vet inte, när det gäller standarderna för vad du köper hårdvara klokt, kan du lika gärna köpa ganska bra hårdvara så om du inte använder den hårdvaran på det sätt som den bör användas, så betalar du för mycket eftersom du betalar för grundläggande prissättning när dessa kärnor inte utnyttjas så att blir ett problem.
Så, varje version av SQL har ett annat sätt på vilket licensiering tillämpas vilket till och med gör det lite förvirrande. Så du har några utmaningar runt det och det är en stor del av varför den här informationen är till stor hjälp eftersom vi kan berätta vilken version det är, vi kan tydligt säga hur många kärnor du har, om dess äldre versioner av SQL det var prissättning per socket, vi kan fortfarande tydligt visa det också. Så det bara, det gör det mycket enklare för en rutin som du måste gå igenom när det är dags att förverkliga det.
Dez Blanchfield: En sak som kommer att tänka på för mig, oh sorry go—
Robin Bloor: Det är okej, du går i Dez, jag skulle ställa en eventuellt irrelevant fråga.
Dez Blanchfield: Bara något riktigt snabbt medan du är med om ämnet du är på nu - såg mycket mer antagande av molnmiljöer och om de kör detta i vårt eget vårt datacenter, i vår egen miljö, de kryper runt och hittar, upptäcker saker är relativt enkelt .
Hur kan vi, hur hanterar vi scenariot där vi kan ha tre datauppsättningar, två moln och synlighet i dessa miljöer är brandväggad och ofta finns en datauppsättning i slutet av ett rör eller en VPN. Finns det bort att upptäcka från frontend eller måste vi, för att börja öppna portar så att vi kan skanna över vissa miljöer mellan ett slags moln och utanför lokaler där plattformarna körs?
Bullett Manale: Ja det skulle det vara, det skulle vara något övervägande när det gäller hamnarna. Så dess, tyvärr önskar jag att jag skulle kunna säga att det kommer att bryta igenom alla dessa miljöer men det finns några olika alternativ som du kan göra med detta. Uppenbarligen, om du gör något som Amazon EC2, allt du behöver egentligen är tillgången till den miljön genom din anslutning, förutsatt att dina portar är öppna och sedan kan specificera dina IP-adresser eller din domän som är associerad med det och det kan starta samlingen och börja upptäckten.
Så det är i de typer av miljöer det är verkligen inte ett problem; det är de mer specifika miljötyperna som RDS och där du bara får själva databasen där det kommer att bli lite mer utmanande att se och upptäcka den typen av information.
Dez Blanchfield: Så efter det var det, det finns databaser och databaser. Så till exempel de gamla goda dagarna med att bara ha en väldigt, en väldigt stor databasmotor som anekdoten som jag delade framtill där dess bara en massiv plattform och allt det är att tillhandahålla databas. Dessa dagar är databaser inbäddade i allt, i själva verket finns det två eller tre av dem som bara kör i min telefon bakom appar.
Vilka slags utmaningar ser du med scenarier där du har miljöer från Lotus Notes, med appar bakom dem, SharePoint med databasen på olika internet, och så vidare? I allt drivs allt av databasen i slutändan. Vilken typ av saker ser du där ute och vilken typ av utmaningar ser du att människor står inför bara att försöka kartlägga sådana världar och vad ditt verktyg gör för dem?
Bullett Manale: Tja, jag menar att saken med det är att det du sa - allt behöver en databas nu, så många gånger finns det mycket förmodligen, det finns många databaser som introduceras i miljön som DBA själva inte har gjort medveten om att det inte är särskilt svårt att få en SQL-server installerad i miljön, i allmänhet.
Detta verktyg identifierar också saker som expressdatabaser också, så de gratis versionerna av SQL Server. Roligt nog, när du än en gång pratar med DBA: erna får du inte ett konsekvent svar när det gäller att bry sig om de gratis databaser som finns där ute. Många av dessa applikationer som du talar om kommer att använda den kostnadsfria versionen av databasen. Men organisationerna själva kommer att ha en annan inställning när det gäller vilka som är ansvariga för den databasen beroende på vem du pratar med.
Vissa DBA som jag pratar med, jag kan tänka på förra gången jag var på SQL Server PASS, som är i Seattle, du ställer frågan “Gör du om dina expressdatabaser?” Och det var cirka femtiofemtio. Några av folket, de ville veta om dem som en DBA eftersom de kändes som att de är en del av sitt ansvar även de uttryckta databaser som de fortfarande kunde innehålla kritisk information; de måste fortfarande gå igenom processen att säkerhetskopieras och måste fortfarande se till att allt fungerar ur ett hälsoperspektiv på dem. Men bara att veta att de finns är lika viktigt om inte viktigare.
Medan den andra hälften av folket är: "Hej, var inte ansvariga för de databaserna och allt som de lägger på dem är på uppmärksamhet för den person som installerade dem." Men jag skulle säga att det som ni sa, allt ganska mycket nuförtiden har en applikation knuten till den som bara bidrar mer till komplexiteten och förvirringen av att behöva lagra den informationen.
Dez Blanchfield: Ja, jag har sett några, statliga webbplatser är förmodligen min favorit men oftast ser jag inte i företagsmiljöer, var är det, som du sa, att folk glömmer att jag till och med, när de installerar något som SharePoint eller som självutbyte så att du vet att de kommer med en gratisversion som bara är inbyggd eftersom de vill, du vet, installera den snabbt och inte oroa dig för att behöva gå och köpa licensiering.
Då blir det stort och sedan börjar någon klaga på prestanda och de är gilla, "Det är bara din gamla server, din lagring, ditt nätverk, vad som helst," och då blir DBA uppringd och de är som "Tja, du har bara proppade allt i denna gratisversion av databasen, vilket inte är vad du behöver för att utföra den här stora. "
Särskilt när du fick scenarier som Project Manager och Office kör hundratals om inte tusentals projekt över ett stort företag eller ett företag och de använder SharePoint med Microsoft Project Server och de dumpar alla sina PMO-saker i den här databasen. Men i främre delen är de gilla, det är bara ett webbgränssnitt. Men egentligen finns databaser och databaser.
Bullett Manale: Ja.
Dez Blanchfield: Så vad är de, ett av de första stegen som människor här antar jag att det finns ett par frågor som vi kanske vill ta in från publiken. En av de första frågorna är var människor börjar? Vad är det första naturliga steget för dem att gå, "Okej, vi måste göra den anonyma versionen av Alkoholiker?"
Weve har fler databaser än vi vet vad vi ska göra med. Hur är en naturlig typ av steg se ut av dem att gå, "Okej måste vi få den här saken och börja springa?" Går de bara kall kalkon eller senare behöver de verkligen börja små och bara få lite erfarenhet av att kartlägga sin miljö ?
Bullett Manale: Jo, jag tror att de sagt att de måste kartlägga miljön. Nu erbjuder Microsoft ett gratis verktyg för att göra det, Microsoft Assessment Planning Tool, det är ett gratis verktyg men det är statiskt. Du gör upptäckten och det är det. Du får en lista över de saker som finns där ute. Vi tog det och sa att vi kan ta ett steg längre låter göra upptäckten, låter hitta vad som finns där ute och låter sätta det i förvaret och låter oss göra det så att det är dynamiskt och vi kan lägga till det, ta bort från det.
Men totalt sett är det största första steget jag tror bara att ta reda på, göra upptäckten. Oavsett om det innebär att du laddar ner vår produkt i rättegång kan du ladda ner den här och testa den i 14 dagar och du kan peka på din miljö och göra samlingen.
Om du redan har ett kalkylblad med ett gäng information som du är lite säker på att informationen är korrekt, har du också möjligheten att gilla importen till CSV som kalkylbladet med all den informationen och göra den delen av det du redan har. Men när det gäller att räkna ut vad du inte vet, är det enda sättet att göra det manuellt gå ut, göra det eller ha ett verktyg som letar efter den typen av saker som den här. Det beslutet som du kommer att behöva göra vid någon tidpunkt är: "Försöker jag automatisera den upptäckten eller åtminstone få en bra bas på vad som finns där först och sedan kanske oroa dig för några av undantagen?" Men för det mesta del du förmodligen behöver ett verktyg.
Dez Blanchfield: Så bara snabbt. Vart går folk för att komma igång med detta? De träffar din webbplats? Hur når de ut och kommer igång med detta snabbt?
Bullett Manale: Om du går till Idera, I-D-E-R-A.com, kommer du att se, och jag kan faktiskt bara verkligen snabbt visa det riktigt snabbt. Över på Idera-webbplatsen kommer du till produkter, gå till lagerhanteraren. Du kan se en nedladdningslänk här. Du bestämmer bara vilken bygg du vill installera på en 64 eller 32 bit, så kommer du igång och du kan börja din upptäckt därifrån.
Robin Bloor: Fantastisk och bra, bra presentation, tack så mycket.
Bullett Manale: Tack.
Eric Kavanagh: Vi har ett par frågor från publiken och väl de till er eftersom vi måste svåra stoppa oss själva idag, men Bullett, igen, bra jobb på demo, bra jobb av vår producent som fångar att det inte visade.
Bullett Manale: Förlåt för det.
Eric Kavanagh: Nej, det här är bra saker, du ger synlighet i kärnan i affärer, eller hur? Eftersom verksamheten driver data och du ger synlighet ända ner till kärnan. Så inte mer vågiga saker; nu kan du faktiskt peka på saker och få det löst. Så bra för dig.
Bullett Manale: Tack.
Robin Bloor: Men det var fantastiskt att se det leva förresten, bra gjort.
Eric Kavanagh: Ja, vi kommer att arkivera den här webcasten för senare visning och sedan kommer vi att ha den upp förhoppningsvis inom ungefär en timme eller två det första arkivet går ibland upp lite längre än så, men se till att låta folk veta det. Med det skulle du släppa er, folkens. Tack igen för att du deltog i Briefing Room, var faktiskt Hot Technologies. Väl komma ihåg dig nästa gång. Var försiktig, adjö.