Av Techopedia Staff, 22 februari 2017
Takeaway: Värd Eric Kavanagh diskuterar databashantering med Dr. Robin Bloor, Dez Blanchfield och IDERAs Binh Chau.
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. Hej och välkommen tillbaka igen. Det är en onsdag, det är klockan fyra östra tiden och de senaste åren betyder det att det är dags för Hot Technologies. Det stämmer, det här är vår show med våra vänner Techopedia - Techopedia.com. Kolla in dem online. De får monster trafik, 1, 5 miljoner unika besökare per månad. Det är mycket webbtrafik. Ämnet idag, "DBA: s dröm: upptäckt och hantering över hela miljön." Ja, det är en stor fråga, särskilt för större organisationer. Det finns en bild om din verkligen, och tillräckligt om mig, slå mig upp på Twitter @eric_kavanagh, jag försöker alltid följa tillbaka och delta i samtal där ute.
Återigen talar vi om databasteknologier idag och verkligen kunna förstå vad som händer i ett brett landskap av databasinstanser. Som många av er vet att när du börjar växa din organisation får du många fler av dessa fall där ute och att hålla ett grepp om det kan vara lite av en intressant utmaning. Jag minns faktiskt för ett antal år sedan, jag hade ett bra samtal med en kille som var chef för datastyrning för CIO: s kontor vid försvarsdepartementet. Och jag berättade för honom alla dessa intressanta saker, vi hade denna fantastiska konversation och jag berättade för honom min bakgrundshistoria om lobbying för öppenhet i federala utgifter, och han skrattade och han sa, "Åh, så det är ditt hus där jag ska skicka det nästa rovdjur drönar strejk. ”Han sa, ” Öppenhet i federala utgifter? Jag vet inte ens hur många Oracle-licenser jag har här. ”När jag hörde det kunde jag verkligen uppskatta storleken på utmaningen som vissa organisationer står inför.
Nu i dag finns det massor av intressanta verktyg - vi får höra om ett idag - för att förstå vad som flyger där ute, men till och med för 20 år sedan var det en riktigt allvarlig utmaning. När det gäller organisationer av storleken på DOD kan du bara tänka dig att det kommer att spara mycket pengar att få ett handtag om det kommer att spara mycket tid, det kommer att lösa några styrproblem; du slutar lösa flera utmaningar på en gång om du gör den här typen av saker på rätt sätt. Vi får lära oss om det idag.
Vi har vår egen Dr. Robin Bloor på, chefanalytiker för The Bloor Group. Vi har Dez Blanchfield, vår datavetare, som ringer in underifrån, Sydney, Australien. Och Binh Chau, senior produktchef för IDERA, är också på väg.
Vi gör #HOTTECH som hashtaggen - känn dig fri att tweeta bort under showen. Och vi litar på er för goda frågor, så var snäll inte blyg: ställa frågor när som helst med hjälp av Q & A-komponenten i din webcastkonsol eller det chattfönstret, oavsett sätt. Och med det ska jag överlämna det till Dr. Robin Bloor. Låt mig lämna honom nycklarna till WebEx. Där går den och tar bort den.
Dr. Robin Bloor: Okej. Tja, här går vi, låt oss gå vidare till den första bilden. I Italien kallar de dem Stanlio och Olio, Laurel och Hardy. Tillbaka på 1990-talet när alla var oroliga för år 2000 blev jag involverad i ett antal år 2000-projekt. Och jag gick till - låt oss kalla dem ett stort försäkringsbolag - och de upptäckte att de hade över 500 ansökningar som de inte visste fanns på mainframe. De tog en inventering av stordatorn. Tja, i dessa dagar var mainframe-miljöer mycket bättre omhändertagna än något som kom senare, jag menar, det är bara ingen fråga om det.
Jag var verkligen bedövad och jag pratade med människor i organisationen och de sa att det inte fanns någon central central … det fanns ingen person som var ansvarig för att veta den informationen, du vet, i princip. De tog aldrig inventeringar av sina tillgångar. Och en databas är en tillgång i inga osäkra termer eftersom den innehåller data och data är värdefulla. Hur många fall är frågan och var är de egentligen? Det här är bara “Vad är en databas?” Och skälet till att jag tänker så är en databas ett skåp som man kastar in data i. Och jag pratade nyligen med en webbplats som hade tusentals instanser av Oracle. Oracle är en databas som, om du använder den på något sofistikerat sätt, kräver en DBA.
Jag frågade något om det och de sa att de, ungefär, jag tror att det handlar om sju eller åtta DBA i hela organisationen. Och jag sa, du vet, "Vem sköter de andra tusentals instanserna?" Och de sa: "Ja, det som egentligen har hänt är att människor bara använder det som ett filsystem. Vi har ett antal databaser som finns på stora kluster där prestanda verkligen betyder något och de har DBA som står över dem hela tiden. Och sedan har vi tusentals andra databaser som ingen ser alls över. ”Och jag frågade dem exakt hur många databaser och de kom med, ” Tja, förra gången Oracle granskade det. ”De gjorde inga revisioner själva, du vet, vilket är typ av en intressant sak.
Men, du vet, det finns skäl för att använda en databas. En databas implementerar en datamodell. Den är där för att dela data: kan hantera flera samtidiga begäranden om data, implementera en säkerhetsmodell, är ACID-kompatibel, är elastisk eller kan ställas in för att vara elastisk, du vet. Det är anledningen till att vi har databaser. Men du vet, det är inte ovanligt att stöta på webbplatser med tusentals instanser av SQL Server eller Oracle och de flesta av dem används bara som filsystem, i princip. Och så varför skulle du skapa en ny instans, egentligen?
Jag känner till utvecklargrupper att om de bygger en ny applikation så bygger de den i en silo så att varje given ny applikation skulle ha en separat databas. De skulle inte nödvändigtvis försöka göra ett dataskikt ur saker - jag tror inte att det är bra praxis. Men där igen, du vet, om du har en mycket komplicerad miljö blir det väldigt, väldigt svårt att försöka sätta ihop alla databaser som är relaterade till varandra när det gäller att ha data inom dem där det finns relationer. Instanser skapas för kopior.
Du kan veta att du kan ha heta standbys eller kopior för tillgänglighetsändamål, men du har också kopior eller halvreplikat i datamars. Och när datallagervärlden introducerades, frågan om, du vet, hur många datamarker som fanns där ute, och människor bara använde dem som klonfiler, tog data ur datalageret och inte särskilt bryr sig om dess prestanda i känna att de bara skulle göra sig som standardprestanda. De flesta av dessa människor visste förmodligen inte ens att du faktiskt kunde ställa in databaser. Jag har sett mönster som har skärmad data i distinkta högar för distributionen.
Du vet, du får ofta denna replikationssituation där du har flera depåer inom en organisation och de har båda databaser och var och en är en skärv av en central databas. Du får fall från skärning. Dåliga designbeslut - Jag har sett att några riktigt bisarra konstruktioner äger rum när det gäller databaser där människor har skapat separata databaser utan gott skäl. Och som jag har noterat är databaser filsystem.
Och så finns det test- och utvecklingsmiljöerna som måste stå upp och falla ner, men de räknas alla som databasinstanser och alla måste förresten ha säkerhet och allt annat som databasen förhoppningsvis ger. Hänsyn till instanser - en databasarbetsbelastning kan bara optimeras för en specifik instans. Om du verkligen är intresserad av att ha absolut bästa prestanda är det inte nödvändigtvis att ge dig den typen av optimering att ha data avskärmad i massor av databaser.
Det finns en anledning att inte skapa falska instanser av data. Blandade arbetsbelastningar i samma databas som kontrapunktet kan leda till dålig prestanda - särskilt märkbart av OLTP och stor frågetrafik blandas helt enkelt inte, har aldrig blandat och förmodligen kommer aldrig att blandas. Det är oftast bäst att konsolidera en databas på servernivå snarare än att ha flera VM: er. Men VM: er ger isolering; för vissa människor är det ett designbeslut att isolera data från andra data så att du vet om applikationen misslyckas eller om databasen misslyckas inte min applikation.
Problemet med det är naturligtvis att du hamnar i nästa punkt, som är databaslicensavgifter. Dessa varierar, men jag har sett databaslicensavgifter bli ett designkriterium eftersom någon inte ville spränga ett visst nummer, och därför designar människor dåligt system helt enkelt på grund av att databaslicensen fungerar. Och det är den andra saken: om du börjar konsolidera alla dina databaser är det värt att notera att DBA är dyra. Det är inte så lätt att göra.
En enkel bild av världen - och det här är den sista bilden verkligen - det finns ett dataskikt, det finns ett transportlager och det finns ett bearbetningslager. Och all hårdvara sitter under det. Det är inte riktigt möjligt att optimera datalagret utan att veta exakt vad som finns i det och varför.
Och efter att ha sagt det, ska jag vidarebefordra till min vän underifrån, Dez Blanchfield.
Dez Blanchfield: Tack, Robin. Låt mig bara hämta min mus här. Så jag ska ge oss ett par anekdoter idag eftersom det här är ett enormt ämne och jag kunde tillbringa två veckor med en whiteboardmarkör och ha kul med det, för jag har haft nästan tre decennier av upp- och nedgångar i det här utrymmet .
Men först en mental visuell bild. När jag tänker på den utmaning som vi pratar om idag - och i grund och botten, vi talar om databastillväxt, replikering och spridning och alla utmaningar som följer med det - ville jag bara lägga den här bilden av en gigantisk ek i vår sinne. Det här är berömda vackra träd, de börjar som en liten ekollon men de växer till dessa behemoter. Och när de gör det är de väldigt stora och röriga. Och som du kan se från den här bilden, som en visuell metafor, om du vill, du vet, grenar som går överallt och sedan kvistar som kommer från dessa och lämnar i slutet av dessa och de är i alla slumpmässiga, kaotiska former, och det är bara den bit vi kan se ovanför marken.
Jag tänker på sådant som data i databasen, och nedanför finns det en struktur med rötter och de utnyttjar alla slags riktningar. Men det verkar mycket rent och förnuftigt vid markytan där det är trevligt och platt, men verkligheten är att den är lika galen under marken som den är över marken; vi ser det bara inte. Och jag använder ofta det här när jag börjar tänka på hur jag ska beskriva den utmaning vi pratar om idag till organisationer från styrelserummet till teknikerna för att försöka få dem att visualisera vad som faktiskt händer i deras organisationer. Eftersom det är så lätt att titta på en datorskärm och se dessa vackra fält med rader och kolumner och tänka, "Vi har fått det ordnat, det är inte så stort." Men så är det inte alls. Och så är det vid den punkten jag brukar träffa den här raden som säger att databaser i mitt sinne är som ekollon, du vet, de börjar små och växa, men innan du vet ordet av det har du en skog av jätte- ek, och därmed det visuella.
Så två anekdoter bara för att dela ett scenario som växte ut ur kontroll och bara inte kunde fixas, och sedan en annan som gjorde en liknande sak men kunde fixas, och jag kommer att belysa nyckelpunkten i dagens diskussion kring hur vi kom till det.
Det första var ett scenario där en CIO med de flesta avsikter över tid oavsiktligt orsakade en av de mest oväntade och oönskade sprutorna som bara växte utanför kontrollen. Det var ett scenario där en statlig organisation med tusentals anställda, mycket tekniskt kunnig personal, krävde tillgång till dess system och verktyg som de kunde börja samarbeta med och automatisera mycket av sina processer. De ville komma ifrån pappersformulär och de ville skapa onlinesystem, de ville fånga upp data och spåra det och övervaka det och rapportera det tillbaka och presentera det tillbaka till sina kamrater.
Och det finns alla slags saker, det finns saker från människor som dyker upp till sina kontor och klockar in och loggar in för säkerhetsändamål hela vägen till vem som beställde vad på cafeterian vid lunchtid. Och så beslutade en välmenad CIO att Lotus Notes var en bra idé eftersom han hade varit på en serie seminarier och IBM hade gjort ett bra jobb med att slå upp det och i rätt scenario skulle det ha varit ett bra beslut, hade det har gjorts under kontroll. Men vad som hände var istället för att överlämna Lotus Notes till ett team av tekniska personer för att sortera redskap i en miljö och sedan ställa upp förnuftiga verktyg och så vidare och ge viss kontroll och styrning kring det, vad som faktiskt hände var att det fick distribueras till standarden operativmiljö, SOE, så varje skrivbord blev effektivt en server.
Och så tillhandahöll de utbildning och praktiska anteckningar och dokumentation för hela denna process och alla plötsligt insåg människor, "Ja, jag har Lotus Notes på mitt skrivbord!" Vad betyder det, tror du? Tja, det betydde att tusentals mycket tekniskt kunniga personal fick lära sig att manusera och skriva appar, effektivt, i Lotus Notes, skapa små databaser som i huvudsak såg ut som kalkylblad, rader och kolumner och fält och presentera dessa lilla webbgränssnitt genom Domino.
Om jag ville fånga information om något kunde jag bara skapa en liten form och i ett kalkylark-typgränssnitt, lägga den i en fil, skapa en liten Lotus Notes-databas bakom den och presentera den som en webbapp och börja samla in information. Och det låter fantastiskt tills det hade körts i flera år och plötsligt insåg de, någon vaknade och sa: ”Tja, varför finns det 10.000 nya databasdrivna appar som visas på LAN, och särskilt under de senaste 12 månader? Vad händer? ”Tja, vad som hände var, du gav i princip människor en pistol, och den laddades och säkerheten var avstängd, och naturligtvis sköt de sig i foten.
Och det finns den här fantastiska bilden här som jag vanligtvis trycker fram i mitt sinne av en italiensk konstnär som gör den här konstiga saken där han får en lastbil med hö och halm och dumpas i mitten av en konststudio och sedan får en kurator för konststudion att slumpvis skjuta en nål i mitten av den. Och sedan tillbringar han dagar på levande foder, på kamera, går igenom halmen och letar efter nålen i höstacken, som den var. Tills så småningom, efter timmar och dagar, hittar han det och hoppar upp och ner och blir upphetsad. Och i alla fall, italiensk konstnär, vad kan du göra? Men det är ganska humoristiskt och om du någonsin har sett det på nätet eller om du tittar på det på nätet kommer du att hitta det mycket katartiskt.
Här är ett mardrömsscenario där en välmenad teknisk person gav affärsmän - mycket tekniskt kunniga affärsmän - ett verktyg som var tänkt att underlätta deras liv. Men innan länge hade vi frågor som vem som backar upp dem, vem övervakar och stöder dem, var är dessa data, vilken struktur finns data i, vem som poliserar scheman, vad om jag vill skapa en annan version, vilken information finns i dessa versioner, kan jag göra en dev-testintegrationsresa på dessa saker?
Du vet, du kan dra dina egna slutsatser om hur det gick, men det gick inte bra och du kan föreställa dig att bara hundratals terabyte data, och inte säkerhetskopierade, sitter på, effektivt, datorer eller bärbara datorer på skrivbord, några system som inte ens var tillgängliga eftersom människor inte insåg när de stängde av den bärbara datorn klockan 5:30 och tog den hem för att göra arbete som ingen på LAN kunde komma till den applikationen. Det slutade inte bra. Och en hel del data måste rensas upp och manuellt manipuleras och föras tillbaka till ett förnuftigt system; majoriteten av det torkades bara bort och tas bort, eftersom det bara inte kunde tillåtas sprutas vidare.
Sedan min andra anekdot med saker på en helt annan resa. Föreställ dig ett scenario, du har dev, test, integrationer, systemintegrationer, användarkontrolltest, produktion, katastrofåterhämtning, säkerhetskopiering och säkerhetskopia en till 99 och därefter, du har uppgraderingar, korrigeringar och sedan demonstrationsmiljöer från en till 99 och mer. Och plötsligt sitter du där och håller på: "Vänta, vad händer, hänga, vem använder vad?" Du vet, det här är en mardröm som potentiellt väntar på att hända.
Men i det här scenariot, vad som hände, var jag en möjlighet att gå in i en organisation som ville hämta ut en affärsavdelning för förmögenhetsförvaltning från deras kärnbanksplattform och stå upp som en separat organisation i huvudsak en start i ett företag. Utmaningen var, ta vår affärsenhet för förmögenhetsförvaltning och alla människor och teknik och data kring den i de offentliga tjänsterna, skapa en start i vårt eget företag och hugga av det så att det kan köras på sitt eget varumärke.
Detta är en global ledare inom bank, som jag inte kommer att nämna. Vi var tvungna att utvinna affärsenheten för förmögenhetsförvaltning och alla saker kring den. Så allt i sin helhet, all personal, fysisk infrastruktur och flytta den till ett nytt kontor. Alla affärssystem, all mjukvara, all data, all licensiering, namnger du det. Du kan tänka dig att det såg ut som en mardröm att börja med.
Och för att sätta lite sammanhang runt det, pratar vi om 78 system i den ursprungliga bankplattformen som stöder cirka 14 kärnprodukter, vilket kan vara ungefär tusen olika erbjudanden. Hundratals och hundratals live-databaser som används, och när jag säger i bruk, var vi tvungna att flytta dem på plats, så på en fredag eftermiddag skulle de vara i en miljö, på måndag förväntas de vara någon annanstans och på lördag och söndag var de tvungna att ha denna övergång där transaktioner gick från ett system till vänster, låt oss säga, för att visualisera det, till ett annat system till höger.
Cirka 15 000 kunder med otaliga poster vardera och en ETL-mardröm eftersom inget av de 78 systemen på ena sidan matchades av system på andra sidan. Vi hade helt ny bankplattform, nya system, ny programvara, nya databaser och nytt schema. Så metadata, fält, rader, kolumner, poster, tabeller, du namnger det, ingenting matchade. Det finns 14 olika aktiva utvecklingsteam, ett för varje produkt. Och när vi byggde denna miljö upptäckte vi att när vi hade utvecklingstest, integration, systemintegration, test av användarnas acceptans, produktion, katastrofåterhämtning, demonstrationskopior, säkerhetskopior, uppgraderingar, patchning - jag saknade till och med en där - utbildning, till exempel och utbildning fanns det 23 versioner av var och en av dessa miljöer för varje utvecklingsteam.
Nu sitter du där och plötsligt börjar ditt blod att krama och din hud blir kall och håret står - det kan aldrig sluta bra. Det visar sig, det slutade väldigt bra eftersom det allra första vi gjorde, innan vi ens startade designen av teknikutveckling, var vi gick och fick rätt verktyg. Och vi använde verktyg, och inte nödvändigtvis människor, utan folk som kör verktyg. Vi använde verktyg för att kartlägga data, vi använde verktyg för att kartlägga databaserna som de bodde i, vi kartlade alla metadata, scheman och hela vägen ner till rader, kolumner, post och fält.
Vi visste vad vi kom ifrån och sedan korrelerade vi det med kartan över vad vi satte på plats så långt som den offentliga bankplattformen såg ut, och vi hade en en-till-en-korrelation. Och allt som föll i mitten skapade vi ett datarum där vi skulle gå igenom och manuellt kartlägga dem. Men innan vi genomförde någon installation och någon installation av dessa miljöer i den nya världen såg vi till att varje enskild post, varje enskilt bord, varje fält, varje rad, varje kolumn, varje databas och alla metadata kring det, alla behörigheter och kontroller kartlades, från en till en. Och vi rörde inte en enda sak förrän den korrelationen gjordes.
Och så gick ETL-stycket från att vara en mardröm till en ganska smärtfri process för att bara validera kontrollerna och processerna som följs. Och vi kunde göra detta regelbundet, nästan timme. Vi gjorde övergången från produktion i den gamla världen till nya miljöer med dev, test, integration etc. i den nya världen. Och den dagen vi gick live, efter en femmånaders process att gå live efter en månad med testningen och sedan på sex månader var det online och aktivt, vi hade bara en fråga, och problemet var att någon glömde sitt lösenord och det måste återställas. Det var det enda problemet hade, och skapade i grunden ungefär en timmes stress av människor som tänkte att något hade gått fel - det visade sig att ett lösenord löpt ut och de glömde vad det var och var tvungna att återställa det.
Du kan föreställa dig det scenariot, jämfört med Lotus Notes-miljön där någon hade stora avsikter men inte tänkte igenom utmaningen, och nästa sak var vi tvungna att gå och försöka kartlägga all denna information och huvuddelen av dem måste avskrivas och det var bara en stor förlust av tid och ansträngning och resurs och moral. Till ett scenario där vi, när det är ordentligt planerat och ordentligt gjort och levereras på rätt sätt med rätt verktyg, fick ett bra resultat.
Och så den punkten leder mig till den här raden - innan jag överlämnar till vår medarbetare för att prata om vad IDERA har för att lösa just denna utmaning - är att i dagens värld där allt fler system drivs av databaser är det inte bara en finhet, utan för mig är det ett faktum, det är en nödvändighet, att smarta verktyg, enligt min erfarenhet, är det enda sättet att hantera upptäckt av data, datahantering i skalan och hastigheten som vi rör oss.
Och om det görs rätt, som den andra anekdot som jag just delade förhoppningsvis illustrerat, kan det vara en mycket smärtfri och mycket sömlös process. Inte bara i nya projekt, utan att få dina armar runt en aktuell miljö och se till att du när som helst kan spåra och spåra vad som händer i din organisation, vilken databas som finns där, vilka versioner av databasen kör du och vem använder vad.
Och i det syftet kommer jag att överlämna till vår medarbetare från IDERA, och jag ser fram emot att höra vad de har att erbjuda på bordet och hur de skulle lösa denna mycket utmaning.
Binh Chau: Bra, tack, Dez. Kan ni höra mig okej? Okej tack så mycket. Hej alla, jag är Binh Chau med IDERA. Idag kommer jag att prata lite om produkter som vi har kallat SQL Inventory Manager och det talar om upptäckten och förmågan att lagra dina SQL Server-instanser och databaser där ute och för att få ett grepp om vad du har i miljön och prata om några andra saker som Dez och Robin pratade om när det gäller databasspridning och behovet av data i dag.
Med det här, här är en del övervägande som du har hört, tror jag, anekdotiskt genom de två berättelserna som Dez beskrev. Men i dag finns det så mycket behov av data och affärsgrupper där ute och affärsgrupper där ute snurrar upp sina egna applikationer och servrar, särskilt med SQL Server, eller hur? Eftersom du enkelt kan spinna upp en SQL Express-version eller BI-tjänster, att det bara finns SQL-spridning som pågår i många organisationer, du vet, från det lilla till det stora.
Många gånger är DBA inte medveten om att någon bestämde sig för att starta en instans snarare än att bara sätta en databas på en befintlig instans. De är inte medvetna om dessa saker förrän det potentiellt finns ett problem och någon ringer DBA: "Å nej, min ansökan slutade fungera, den kan inte ansluta till en databas, vad händer?" Och du vet, när DBA frågar några frågor de upptäcker, "Hej, den här var inte på vår radar, vi var inte medvetna om det."
En annan är licenskostnader, eller hur? Microsoft SQL Server-licens: hur det fungerar är att du inte har någon specifik nyckel för det antal instanser du har. Du kan distribuera och sedan göra en granskning. Du vet, de gör en granskning senare och upptäcker hur många licenser du faktiskt behöver. Och så, om de gör en granskning och du inte känner till de okända servrarna, kan det leda till en kostsam revision. Och så är det bra att ha verktyget eller ha en inventering i förväg för att veta vad din licensiering kostar och att inte bara kunna veta utan också hantera det.
Och vad jag just pratade om, om du inte känner till en server många gånger, om det går bra, är allt bra, men den enda gången du blir medveten om något är när det finns ett problem. Och så kan det leda till produktionsavbrott eller kanske inte servern upprätthölls och du fick inte en patch på den servern och det skapar ett problem.
Några av frågorna som en DBA-typ måste ställa dag till dag är att de står inför, du vet, de kan vara administrativa eller strategiska men vissa saker som, Microsoft har precis släppt en kritisk systemuppdatering, hur många system där ute kommer att behöva detta nya lappa? Vem kommer att påverkas av driftstopp om jag behöver ta ner systemet för att korrigera det? Hur kan jag enkelt komma till den informationen? Måste jag gå in i ett kalkylblad? Måste jag gå in i flera system för att hitta det? Måste jag nå de olika affärsgrupperna för att få den listan? Det är verkligen svårt att dela in det.
En annan bra är i princip, någon kommer med och de säger, jag behöver en ny databas. Det kommer att kräva X-storlek och det måste ha så mycket kapacitet, och sedan vill de veta, var kan jag sätta det? Utan att veta vad som finns i ditt landskap är det svårt att säga dem, okej, vi kan sätta det här, här eller här. Du måste typligen gå och göra dina manuella kontroller som behövs för att göra det. Och vi pratade om revisionen och även den skurkiga servern.
Om du har en oseriös server där ute, vet du inte i vilket läge den befinner sig, om den har säkerhetskopierats, om den har alla sina korrigeringar. Ibland kanske du inte blir medveten om dessa saker förrän det finns problem, vilket skulle vara dåligt.
Det är typ av alla utmaningar, frågorna, DBA-ansiktet en dag till dag, vad som kastas på dem. Så jag ville presentera SQL Inventory Manager, som är en produkt som vi har där ute. Det gör ett par saker. Det gör upptäckt, som i princip är typ av att gå ut i din miljö för att se vilka SQL Server som finns ute i din miljö. Och sedan kan den också upptäcka automatiskt, så i princip kan du, när du har kört en upptäckt, ställa in den så att den går ut dagligen eller varje vecka - oavsett tidsram du vill - för att upptäcka nya instanser där ute.
Och då kan du också låta det automatiskt registrera dessa instanser så att du kan börja övervaka dem och kontrollera deras hälsotillstånd och sedan kan du börja katalogisera och inventera dessa instanser så att du kan få en bra bild av ditt SQL Server-landskap. Vad finns där, vad som är produktion, vad som är utveckling, vad som är katastrofåterhämtning, vad som är mindre kritiskt och du vet, vilka applikationer som körs på dem. Och du kan också få varningar för när saker, när hälsokontrollen misslyckas, så i princip om servern går ner eller såväl som ett antal ytterligare saker kan du verktyg själv.
Eric Kavanagh: Du blir lite mjuk, så att du vet.
Binh Chau: Tyvärr är det bättre? Det jag vill göra var att ta er genom en demo, visa er vad det gör. Häng på en sekund, låt mig först dela min skärm. Ser ni killarna på webben? Detta är SQL Inventory Manager-gränssnittet. Skärmen som jag visar dig här, det är ett webbaserat gränssnitt. Skärmen som jag visar dig här är vår databasinstansvy. Över toppen kan du se att vi har annorlunda. Så "upptäckt" är i princip alla de fall som det upptäcks i nätverket. Och vad det kommer att visa mig är i princip.
Eric Kavanagh: Du börjar bryta upp bara lite där. Du kanske vill lägga ner telefonen och sätta den på högtalaren. Varsågod.
Binh Chau: Denna upptäcktskärm visar dig allt som Inventory Manager har upptäckt i ditt nätverk. Här upptäcks det som 1 003 servrar där ute. Och det kommer att berätta versionen, utgåvan, om den kan hitta den, när den upptäcktes och hur den upptäcktes. Låt oss till exempel säga att jag väljer att ignorera några av dessa, vilket innebär att du kanske vill ignorera Developer Edition eftersom de inte är lika viktiga för mig eftersom de bara är Developer Edition; Jag kan välja att ignorera dessa och det kommer att placera dem på fliken Ignorera så nästa gång jag kör Discovery kommer det inte att visa det för mig igen. Nu kan jag fylla i för att göra automatisk registrering eller jag kan registrera manuellt.
Och så här har jag valt att övervaka sex instanser. Och här är den inloggad och den kommer att köra regelbundna kontroller av dessa och sedan finns det flera kontroller, allt här ifrån, du vet, det kontrollerar var 30: e sekund för att se om servern är upp eller ner och det ger dig en slags översikt över vad den staten är. I grund och botten här berättar det för mig att jag har en server som är nere och dessa fem som är uppe. Det berättar också för mig vilka serverversioner, antalet databaser, statusen för databaserna, eventuella ytterligare inventeringar eller metadata runt servern. Jag kan också komma till licensvyen härifrån. Här ger det mig lite av Microsofts licensinformation som jag behöver om jag ville gå före att få en total eller sammanfattning innan en Microsoft-granskning.
Här är antalet kärnor, antalet uttag, den möjliga kärnlicensen som var något som Microsoft introducerade från och med 2012. Det var vår instansvy. Vår översiktssida, det här är den sida som du öppnar upp för. Detta visar dig de hälsokontroller eller rekommendationer som den har, som just nu berättar det för mig att jag har nio databaser som inte har aktuell säkerhetskopia. Jag kan klicka in där för att gå ner till detaljerna i vilka databaser de är och jag kan gå in och vidta en åtgärd på dem om jag behövde det. Det berättar för mig alla toppdatabaser efter storlek, toppdatabaser efter aktivitet. Jag kan klicka på den specifika servern och få mer information om den.
Eric Kavanagh: Medan det rullar, vad du visar oss här är förmågan att se verkligen allt som är anslutet till nätverket, är det inte?
Binh Chau: Rätt. Detta visar allt jag har valt att övervaka med hjälp av Inventory Manager. Detta är en SQL Server, det visar mig här alla applikationer som är anslutna till servern. Återigen kan jag få in alla databaser som är associerade på den här servern. Här över kunde jag tagga saker. Jag kan skapa en tagg för den här servern, oavsett om det är en exakt domän eller inte. Vi har kunder som använder den för, till exempel, de vill märka sina produktionsservrar eller sina skuldservrar och sedan kan de få en fullständig rapport om hur saker är. När jag går till fliken Administration är det här jag kan köra Discovery. Och Discovery kommer i princip att gå ut och springa in i ditt nätverk och hitta alla SQL Server i din miljö.
Här har jag den här exakta domänen som är en domän av oss och jag har ställt in den för att säga, du vet, på just den här domänen använd detta specifika Windows-användarkonto för att upptäcka och jag vill att du ska göra en fullständig genomsökning. Jag kan också välja att specificera "Endast skanna det här underdomänet" eller "Endast skanna föräldern." Men i det här fallet har jag sagt här kör hela skanningen. Här är de olika skannetyperna jag kan använda och om jag sparar det, och i princip är det ett jobb som jag kan ställa in. Just nu är det av, vilket betyder att jag måste köra dessa skanningar manuellt. Men om jag ville, kunde jag ställa in det dagligen, du vet, köra jobbet dagligen. Eller om jag väljer att inte köra det dagligen - det är för mycket - kan jag säga köra jobbet varje vecka på ett specifikt datum och tid.
Och sedan Auto-registrering här, om detta är påslaget, vad det skulle göra är att varje gång den hittar en ny server kommer den automatiskt att registrera den i Inventory Manager så att jag kan börja övervaka den. Om det finns någon form av utgåva som jag vill utesluta, till exempel, jag bryr mig inte om Express- eller utvecklarutgåva eftersom det är utvecklingsmiljö, då skulle jag bara klicka på de här och vad det kommer att göra är att det bara säger varje När jag hittar något nytt kommer jag bara att lägga till det i Inventory Manager så att du kan övervaka det så länge det inte är en Developer- eller Express-utgåva.
Och här kan jag ställa in taggarna, så till exempel om jag har produktionsservrar kan jag gå hit och tagga dessa servrar. Jag kunde märka antingen databas eller server med en specifik blå tagg, så jag kan till exempel säga att denna AO_NODE borde ha en produktionstagg. Och på det här sättet om jag behövde enkelt komma till servern, kan jag gå ut här och klicka på produktionstaggen så tar det mig direkt till dessa två servrar. Det här är vår Explorer-vy och detta visas av ägaren, men jag kan säga med instans-taggen, också av databaser och jag kan utöka detta för att se vad de är.
En annan användbar funktion som vi har byggt som människor verkligen gillar här är förmågan att titta på vad du hanterar genom Inventory Manager och se vilken patch-nivå de är på. I grund och botten, här berättar jag här de sex servrarna som jag har hanterat i mina verktyg, huruvida det finns en uppdatering tillgänglig för Microsoft eller huruvida versionen jag är på, om den stöds eller inte, och supporten status. Om jag ville ta reda på mer om den här snabbkorrigeringen kan jag klicka på den och den kommer att länka mig till artikeln från Microsoft när det gäller vad hotfixen handlar om och om jag ska adressera dem. Du kan exportera den här listan om du ville, så på det sättet kan du säga: "Hej, jag måste kanske lappa tre av dessa servrar i helgen och de tre andra senare."
Bygglistan - så det finns en lista som den kontrollerar mot att se att din version är uppdaterad. Du kan gå ut och ladda ner listan för att se till att den är uppdaterad och att du har den senaste listan att jämföra den med. En annan snygg inventeringsfunktion som människor gillar är förmågan att lägga till, inte bara taggar utan också möjligheten att lägga till anpassade inventeringsfält. Om du vill lägga till ett fält här för att tagga en databas till exempel, låt oss säga att jag vill tagga det på databasnivå. Avdelningen, den här avdelningen och den här databasen, jag kunde göra det till en annan typ: öppet slut, sant / falskt eller picklista.
Och jag kan säga, du vet, det här är en HR, marknadsföring, FoU, finans. Och vad detta gör här är i grund och botten, när du väl kan tagga dessa saker kan du få lite information härifrån som säger hur mycket kapacitet varje databas använder och sedan kan du börja typ, växer den och är det vettigt att ladda tillbaka dessa avdelningar?
En annan sak är, du vet, om du måste köra underhåll, genom att veta vem som är i den databasen kan du veta vem du ska kontakta för att låta dem få veta, "Hej, jag måste köra underhåll i helgen, dina databaser kommer att vara offline, " och så vidare. En annan användbar funktion är sökrutan där folk gillar. Många gånger DBA: er frågas om en databas eller en applikation eller en server, beroende på vem som pratar med dem, är det lite svårt att ta reda på exakt var det är. Vad du kan göra här är att du kanske inte vet var databasen bor men du kan bara skriva in den. Jag kan bara skriva in IDERA Dashboard och det kommer att dra upp ett par databaser och var de sitter så att du enkelt kan få till dem. Och sedan hämtar det ytterligare information om dem: deras storlek, en loggstorlek, oavsett om det någonsin har haft en säkerhetskopia, vilket återställningsläge det är i, om jag ville lägga till några taggar om det. Det finns många olika funktioner i det här verktyget, du vet, det är ett inventeringsverktyg men det är ett inventeringsverktyg som är mycket specifikt för SQL Server och för DBA.
Eftersom det antas att ytterligare saker som DBA skulle vilja ha tillgång till eller för att få en bra bild av hur miljön och deras landskap ser ut för deras databaser. Du kan också prenumerera, konfigurera SMTP-servern och ställa in prenumeration för att varna för dig själv eller för användare här. Jag kommer att stoppa detta och gå tillbaka till presentationen. Och den sista bilden här är bara en enkel bild av arkitekturen. Det är en webbkonsol som körs på en inbäddad Tomcat Web Services.
Vi har några insamlingstjänster och hanteringstjänster som vi lägger in i ett lager och hanteringstjänsterna går ut och kör Discovery på dina olika SQL Server-instanser. Det finns inget installerat på dina bildskärmservrar. Vi har jobb som körs med jämna mellanrum som bara samlar in data om det, så i princip om det är upp eller ner, hur mycket data som används, vad människors andra versioner är. Det är allt.
Eric Kavanagh: Ja, låt mig ställa dig - jag ställer ett par frågor och sedan är jag säker på att Robin och Dez har några också - bara av nyfikenhet, när någon kommer in för att göra en revision, låt oss säga Microsoft, är de använder det här verktyget, eller antar jag att de har några egenverktyg som de använder?
Binh Chau: Ja, jag tror att de använder egna verktyg. Saken är att detta verktyg är ett inventeringsverktyg så det håller sig uppdaterat när det gäller, för det har jobbet att gå ut och kontinuerligt samla in information om dina servrar, det kommer att springa ut där och när som helst. du kommer att ha aktuell information, faktiskt om hur saker och ting förändras kontra du vet, engångsrapporter som du kan få från Microsoft för att säga att det här är antalet servrar du har, det är de versioner du har .
Eric Kavanagh: Ja, jag är nyfiken på Discovery. Så när någon köper detta verktyg och börjar använda det, hur sker upptäckten egentligen? Detta var typ av vad jag hänvisade till tidigare, med andra ord, knackar du på nätverket för att se vilka signaler som flyger ut där som verkar vara databasinstanser och sedan katalogiserar du det och sedan när du har taggat en databasinstans som övervakar du? Jag antar att den har en sorts ping som den gör så ofta och om den tappar, till exempel, så vet du att den är nere. Är det sådant hur saker fungerar?
Binh Chau: Ja. Jag menar, när du har aktiverat Discovery går det ut till ditt nätverk och vi har flera olika skanningar att gå ut där, men det gör, du vet, en webbläsarscanning och registerskanning. Det gör olika skanningar för att se vilken dator som finns där ute och sedan gör det en kontroll: har du SQL-servrar där ute eller BI-tjänster där ute? Och sedan tar den tillbaka och drar in det i verktyget och visar det till dig, "Hej, här är alla saker som jag upptäckte."
Och om du skulle säga "Jag vill övervaka med det här verktyget", kommer det att hålla reda på det och det kommer att pinga det. Det har jobb att pinga in det så ofta för att säga: "Okej, kolla detta nu om det här, " - du vet, databastillgängligheten - kolla det nu om databashistoriken, kolla databassidan. Det kör en serie jobb för att kontrollera databasen som du övervakar.
Eric Kavanagh: Ja, det är bra. Och vi har en fråga från en publikmedlem. Jag vet att ni har verktyg som fungerar med en mängd databasteknologier, men den här i synnerhet som ni visar idag, är det bara för SQL Server eller täcker detta även andra databastyper?
Binh Chau: Just nu täcker det här verktyget SQL Server.
Eric Kavanagh: Okej, det är bra. Låt mig överlämna det till Robin, jag är säker på att han har några frågor, sedan kanske tillbaka till Dez. Robin?
Dr. Robin Bloor: Ja, säkert. Microsoft ganska nyligen - någon gång 2006 - meddelade SQL Server på Linux, men jag tror inte att den har levererat den ännu. Jag undrade bara om du fick några kommentarer om det. Är du medveten om det? Leker du med det?
Binh Chau: Ja, det är vi. Vi planerar att inkludera det. Jag menar, det trevliga med det här verktyget är att jag har pratat med många kunder som har byggt sina egna hemodlade verktyg för att på samma sätt göra samma sak, men de måste hålla jämna steg med de nya utgåvorna och versionerna som Microsoft kommer ut med, men vi har nya versioner och utgåvor, vi kommer in på det tidigt för att se till att verktyget kommer att kunna kontrollera och hantera de nya utgåvorna. Så SQL på Linux är något vi planerar att lägga till och göra tillgängligt när det är tillgängligt - tror jag senare i år.
Dr. Robin Bloor: Ja, det är intressant. Förväntar du dig att många av dina kunder faktiskt gör det? Jag menar, SQL Server är en mycket sofistikerad databas enligt min erfarenhet. Jag menar, du vet, det är länge i tanden, det är förmodligen saken att säga. Jag menar, du vet, den ursprungliga Sybase som den kom från var faktiskt ganska förenklad i många saker den gjorde. Men Microsoft har lagt till fler och fler saker under åren. Kommer allt detta att finnas tillgängligt på Linux? Jag menar, kommer du att ge dina kunder råd om huruvida de ska flytta den migrationen?
Binh Chau: Jag är ledsen, är frågan ser vi att folk frågar efter det?
Dr. Robin Bloor: Är det så lika sofistikerat på Linux som det är på Windows, med tanke på att du har krossat med det?
Binh Chau: Jag har inte spelat med det själv, men vad jag har hört från en kollega är att det faktiskt är mycket på nivå. Men jag har personligen inte spelat med den nya versionen av SQL på Linux.
Dr. Robin Bloor: Okej. Har jag rätt i att tänka att du helt enkelt har lagt agenter på varje SQL Server du hittar? Är det så här verktyget fungerar?
Binh Chau: Nej, vi sätter faktiskt inte agenter. För det här specifika verktyget, Inventory-stycket, sätter vi inte faktiskt agenter på det. Vi går bara ut och ringer och kontrollerar status på det. En trevlig sak med det här verktyget är att det är agentfritt.
Dr. Robin Bloor: Så har du andra SQL Server-verktyg, kan du påminna mig om vilka andra produkter du har i den här sviten som hanterar SQL Server?
Binh Chau: Ja. Vi har SQL Diagnostic Manager. Det är ett övervaknings- och prestationsverktyg. Det gör mer djupgående analys eller diagnostik och prestanda och hälsokontroller för dig än Inventory Manager. Inventory Manager är den lätta versionen av den hälsokontrollen. Vi har också Compliance Manager och Secure, som är en del av vår säkerhetssvit. Det kommer i princip att berätta vem som har åtkomst till dina uppgifter, vilka uppgifter de har åtkomst till, varför och det hjälper dig att följa och andra rapporteringsriktlinjer. Vi har SQL Safe, som är vårt backupverktyg - det gör säkerhetskopiering och återställning och det är trevligt.
Vi har också vår Enterprise Job Manager som bara övervakar ditt jobb. Och sedan har vi Toolbox-verktyget som är Admin-verktygssatser och även jämförande verktygssatser samt SQL Doctor. Administratörsverktygssats och jämförelseverktygssats, det är vad jag tänker på som en schweizisk armékniv. De har flera verktyg där för att hjälpa DBA att göra olika saker som du vet, kolla korrigeringar eller flytta eller klona en databas. Men det finns 24 sådana verktyg i den verktygslådan.
Dr. Robin Bloor: Är de människor som går för Inventory Management, är de normalt sett redan användare av dina andra verktyg? Eller är den här typen av inträde? Jag kan föreställa mig - jag menar, du kan berätta för mig om du har några krigshistorier - men jag kan föreställa mig om du aldrig faktiskt har gjort en inventering i ett ganska stort datacenter, kan upplevelsen vara ganska nykter. Är det vad du hittar?
Binh Chau: Ja. Jag menar, vi har kunder som introduceras till verktyget från andra verktygssatser, men vi har kunder som kommer och letar efter ett sådant verktyg på grund av projekt som de har. Ett exempel jag har varit där var ett företag som slogs samman med ett annat företag och köpte en serie företag och behövde konsolidera sitt SQL Server-fotavtryck för att minska sina kostnader. Och så letade de efter ett verktyg för att på ett sätt gå ut och upptäcka allt de hade så att de kan starta processen för hur vi konsoliderar detta.
Dr. Robin Bloor: Det förstår jag. Jag antar att det är ganska vanligt med sammanslagningar när du tänker på det. Okej, jag ska lämna till Dez, jag vill inte ta hela tiden. Se vilka frågor vi har från Australien.
Dez Blanchfield: Tack, ja, frågorna är alltid upp och ned här. En av de saker som kommer att tänka på, och jag får detta ganska mycket, du vet, företag är inte riktigt säkra på var de ska dra linjen när de ska börja investera. När bör en organisation - enligt din erfarenhet med tanke på att du befinner dig i den kalla fasen - när är rätt tid att börja investera i verktyg som detta för att säkerställa att du inte får problem? Gör du det från första dagen när du börjar bygga din databasinfrastruktur för den nya organisationen eller, som du just beskrev, när du gör ett förvärv / fusion?
Eller finns det en viss skala du verkligen behöver vara på? Behöver du 10 eller 100 eller 1 000 databaser? Vilken är din upplevelse så långt som marknaden du har jobbat med så länge, när är rätt tid att komma in i detta utrymme och förmodligen var du ska börja? Hur ser det ut när du kommer igång?
Binh Chau: Jag menar, jag tror kanske om det är en väldigt liten organisation kanske du inte har något behov av det här verktyget, till exempel med en DBA eller ett par DBA. När du börjar få en grupp med, jag vet inte, tre eller fyra DBA: er och kanske 50 till 100 servrar, kanske du vill börja göra något liknande. Jag antar att när din organisation blir större i storlek och bara affärsmän som är tekniska kunniga vill, vet du, som det exemplet som du gav, de vill installera applikationerna och databaserna på egen hand, men det är när du vill ha den här typen av verktyg för på så sätt kan du se vad som finns där ute.
Men även i en mindre organisation är det trevligt att ha den här typen av verktyg för att hålla reda på vad du har. Om du delar upp det så att du kan säga, "Åh ja, jag köpte SQL 2012 för den här rutan, men kör för närvarande SQL 2008 eftersom jag har en applikation som fortfarande behöver den äldre versionen." Det hjälper till att ha det inventeringsverktyget bara för att få bort från att hantera flera kalkylark som kan bli inaktuella.
Dez Blanchfield: Den andra frågan jag just har följt om den: vilka typer av färdigheter eller resurser bör organisationer planera att ha när de kommer till den skalan? Är det så att det finns en viss kompetensuppsättning som du verkligen behöver eller en typ av erfarenhet eller bakgrund eller den typ av person som bäst passar denna typ av utmaning? Eller är det något som den genomsnittliga DBA- eller sysadministratören eller skicklighetsuppsättningen för nätverksadministratörstyp kan kasta detta på? Behöver du verkligen en skarp spetsig hjärna eller kan du plocka upp det här ganska snabbt?
Binh Chau: Tyvärr, så du pratade om personens kunskapsuppsättning?
Dez Blanchfield: Ja, så när du tänker på en databasadministratör så finns det en viss uppsättning färdigheter som du skulle behöva. Så när du går ut och anställer en DBA i sig för den specifika rollen, när du tänker på de typer av utmaningar som du pratade om här där du använder ett verktyg som detta för att hålla koll på kartläggning och spårning av databaser, gör upptäcktsdelen och driver detta specifika verktyg, finns det något unikt med användningen av verktyget och tillvägagångssättet för denna typ av utmaning, eller är det något som den genomsnittliga DBA kan ta upp ganska snabbt?
Binh Chau: Jag menar, jag tror att din genomsnittliga DBA snabbt kan plocka upp det. Jag tycker att det är bra att ha den här typen av verktyg eftersom du också kan vända det eftersom det är webbaserat. Du kan ge det till andra användare inom din organisation. Du kan ge den till apputvecklare som kan kontrollera sin specifika databas eller server. Det tar bort några av de administrativa saker som en DBA måste göra. Tidigare skulle någon ringa DBA och säga: "Åh, varför är min server upp eller ner?" Nu kan de få tillgång och se om deras servrar är upp eller ner.
Dez Blanchfield: Och vilken typ av miljö skulle en genomsnittlig organisation behöva för att implementera detta? Behöver den en dedikerad fysisk server, eller kan det göras på en virtuell maskin? Kan de distribuera det i molnmiljön? Vad är det allmänna fotavtrycket för installationen av verktyget och bara den allmänna driften av det? Hur mycket tungt järn behöver det potentiellt för att löpa parallellt med de andra miljöer som det kartlägger?
Binh Chau: Ja, det kan köras på en VM eller en dator eller en server. Det behöver inte nödvändigtvis vara en dedikerad server, det beror bara på hur många servrar du övervakar. Om du har en större miljö kan det hjälpa till att ha en större server eftersom den samlar in mycket data om SQL Server som du övervakar.
Dez Blanchfield: rätt. Är det den typen som du bekvämt kan köra i molninstansen och skapa en VPN tillbaka till din miljö, eller är mängden data den samlar förmodligen lite tung för den typen av användning?
Binh Chau: Vi har inte ställt in det för att köra det på molnet, för att köra detta i molnet ännu. Det borde förmodligen köras på prem.
Dez Blanchfield: Och sista frågan, om jag kan: en hel del av de verktyg som jag har sett i detta utrymme, särskilt där du nämnde det för ett scenario där någon förvärvade företag eller fanns en sammanslagning eller något därtill, eller till och med om det var en organisation som bara slår samman affärsenheter, är det ett förnuftigt användningsfallsscenario där någon distribuerar den på en bärbar dator och tar den in i en miljö för att kartlägga en värld som en gång, eller är det ett osannolikt scenario med användningsfall Är det mer sorts fall att det kommer att finnas där och bara permanent kvar att köra?
Binh Chau: Det här specifika verktyget är mer en typ av, installera på en server och det finns kvar för att köras. På det sättet kan du samla in den information du behöver för den och hålla, antar jag, en löpande inventering av vad du har. Det är till skillnad från kartverktyget eftersom kartverktyget är typ av en-mot-en, hoppa till den port du behöver, gör vad du behöver göra med det idag. Den här är typ av - den trevliga delen med det är det faktum att du kan typ tagga det, ge folk tillgång till det för att kontrollera tillståndet för deras specifika server, de som de är intresserade av.
Dez Blanchfield: Okej. Förmodligen den sista frågan för mig och sedan kommer jag att lämna tillbaka till Eric för frågor som kommer genom Q & A-fönstret med de deltagande, eftersom vi har haft ett bra val i dag, en av mina favoriter. Bara för att ta bort detta, vad är processen för att få tag på detta? Jag vet att många av dina verktyg finns tillgängliga för saker att testa innan du köper. Vart ska människor gå för att lära sig mer om detta på nätet, var platsen på webbplatsen ska de leta efter nedladdningarna och hur ser resan ut, på något sätt göra ett bevis på ett koncept eller en rättegång och ta hand om det och bli bekant med det att sedan kontakta och köpa det?
Binh Chau: Ja. Du kan gå till IDERA.com-webbplatsen och du kan ladda ner en test på två veckor gratis. Och om du gillar det och du vill nå ut till oss kan vi också schemalägga en demo med en av våra ingenjörer för att på ett sätt göra ett djupare dyk i verktyget.
Dez Blanchfield: Fantastiskt. Tack så mycket för det. Jag uppskattar tiden att chatta med dig om, och utifrån min personliga erfarenhet och jag är säker på att jag talar för Robin om detta på hans livslånga erfarenhet, tror jag att det är givet att något liknande är ett krav nuförtiden. Vi kan inte göra det manuellt nu oavsett hur hårt vi försöker; skalan är bara för stor och saker rör sig för snabbt.
Jag rekommenderar folk att göra exakt det, hoppa på IDERA-webbplatsen och få en kopia att leka med. Eftersom den potentiella risken för min egen erfarenhet med anekdoterna jag delade just idag, har det varit att det snabbt kan gå från mycket dåligt till mycket bra, om du har rätt verktyg, men det kan också gå åt andra hållet om du inte gör det. t. Eric, tillbaka till dig.
Eric Kavanagh: Ja, bara poppa för en sista fråga till dig, en intressant. Jag är bara nyfiken på att veta vad du ser där ute, du vet, molnet är uppenbarligen allt viktigare i dag - Amazon Web Services, men de är inte de enda, Microsoft har hela Azure-erbjudandet det verkar ta fart. Jag är nyfiken på att en av de deltagande skriver att Dr. Bloor gjorde en intressant poäng om att DBA är dyra och att hanteringsproblem orsakade av antingen en skurk DBA eller någon som inte gör vad de borde göra, kan det lösas genom att migrera till molnet. Jag är verkligen bara nyfiken på hur mycket aktivitet du ser? Ser du att migrera till molnet blir en större fråga för företag, eller vad tar du på det precis som en trend?
Binh Chau: Jag känner att det bara beror på vilken typ av problem du är i. Jag känner som vissa branscher som de säger, "Nej, vi migrerar inte." De kanske inte flyttar till ett offentligt moln; de kanske tittar på att migrera eller migrera sina saker till ett privat moln. Men då ser jag några organisationer som är intresserade av att du verkligen kommer in på snabbspåret och på sikt går mot en Amazon eller Microsoft Azure. Och så finns det några som säger: "Nej, vi migrerar inte våra data" eller "Det finns bara vissa uppgifter som vi skulle migrera, men inte våra kritiska." Jag tror att det finns en typ av tre läger.
Eric Kavanagh: Ja, det skulle vara vettigt. Jag menar, vi ser det mer och mer och jag tror att det kommer att röra sig i passform och börjar ganska länge. Och det finns en motreaktion till molnet också. Människor kommer in på Amazon Web Services - vi har hört det mer än några gånger - och till en början är kostnaderna hanterbara och sedan med tiden kryper det bara upp och sedan sitter du lite fast där. På många sätt är molnet bara ett annat datacenter, men det kommer att bli mildare en intressant resa framöver.
Tja, folk arkiverar alla dessa webbsändningar. Hoppa online till techopedia.com för att kolla in en komplett lista över alla saker som vi gör. Och naturligtvis insideanalysis.com för allt det senaste. Och med det kommer vi att ta farväl. Och tack så mycket igen för din tid och uppmärksamhet. Tack för alla våra vänner på IDERA och vi pratar i morgon förhoppningsvis för vår datafilosofi som kulminerar webcast. Det stämmer, Philosophy of Data är imorgon klockan fyra östra. Hoppas att vi ses där. Var försiktig folk, adjö.
