Av Techopedia Staff, 19 april 2017
Takeaway: Värd Eric Kavanagh diskuterar prognoser med Dr. Robin Bloor, Rick Sherman och IDERAs Bullett Manale.
Du måste registrera dig för den här händelsen för att se videon. Registrera dig för att se videon.
Eric Kavanagh: Mina damer och herrar, hej igen och välkomna tillbaka till Hot Technologies webcast-serie! Jag heter Eric Kavanagh, jag kommer att vara din värd för dagens webbseminarium, som heter "Spara tid, pengar och problem med optimala prognoser." Kurs Jag missade den första delen av titeln där, "De bästa planerade planerna." Vi prata alltid om det på den här showen. Så Hot Technologies är naturligtvis vårt forum för att förstå vad några av de coola produkterna finns ute i världen idag, världen av företagsteknologi, vad folk gör med dem, hur de fungerar, allt det där roliga grejer.
Och ämnet idag, som jag föreslår, handlar om prognoser. Du försöker verkligen förstå vad som händer i din organisation. Hur ska du hålla dina användare lyckliga, oavsett vad de gör? Om de gör analys, om de gör riktigt arbete, möter de riktiga kunder med transaktionssystem, oavsett vad som är fallet, vill du förstå hur dina system går och vad som händer, och det är vad vi " Jag pratar om idag. Det är ganska roligt eftersom prognoser inte är något jag gillar att göra, för jag är vidskeplig, som om jag tror att om jag förutspår för mycket kommer dåliga saker att hända, men det är bara jag. Följ inte min ledning.
Så här är våra presentatörer idag, dina verkligen i det övre vänstra hörnet, Rick Sherman ringer in från Boston, vår kompis Bullett Manale från IDERA och vår helt egen Dr. Robin Bloor. Och med det kommer jag att överlämna det till Robin och bara påminna folk: Ställ frågor, var inte blyg, vi älskar goda frågor, vi lägger ut dem till våra presentatörer och andra idag. Och med det, Robin, ta bort det.
Robin Bloor: Okej, när jag är i polpositionen som de säger, trodde jag att jag skulle berätta en SQL-historia idag, för det är bakgrunden för vad diskussionen som kommer att pågå och det oundvikligen inte kommer att kollidera med för Rick fokuserar inte på detta och kommer inte att kollidera med vad Rick har att säga. Så SQL-berättelsen, det finns några intressanta saker med SQL eftersom det är så dominerande. Se, det är en skrivfel, SQL är ett deklarativt språk. Tanken var att du kunde skapa ett språk där du skulle begära vad du ville ha. Och databasen skulle räkna ut hur man får den. Och det har faktiskt fungerat ganska bra, men det finns ett antal saker som är lika värda att säga om det, följderna av att basera hela IT-industrin på ett deklarativt språk. Användaren känner inte till eller bryr sig om den fysiska organisationen av uppgifterna, och det är bra med det deklarativa språket - det skiljer dig från allt detta och till och med oroar dig för det - bara fråga vad du vill och databasen kommer att få det.
Men användaren har ingen aning om hur de strukturerar SQL-frågan kommer att påverka resultatet för frågan och det är lite av nackdelen. Jag har sett frågor som är hundratals och hundratals rader långa, som bara är en SQL-begäran, du vet, börjar med "select" och fortsätter bara med subfrågor och så vidare. Och det visar sig faktiskt att om du vill ha en viss insamling av data ur en databas, kan du be om det på många olika sätt med SQL, och få samma svar om du typ har lite kännedom om data. Så en SQL-fråga är inte nödvändigtvis det bästa sättet att be om data, och databaser kommer att svara helt annorlunda beroende på SQL som du lägger in dem.
Och så påverkar SQL faktiskt prestanda, så att människor som använder SQL, det är sant för dem, det är också sant för SQL-programmerare som använder SQL och de är ännu mindre benägna att tänka på effekterna de kommer att få, för de flesta av deras fokus är faktiskt på manipulering av data och inte på att få, lägga till data. Och detsamma gäller också för BI-verktyg, jag har sett SQL som, om du vill, pressar ut BI-verktyg i olika databaser och det måste sägas att mycket av det är, ja, jag skulle inte t skriva SQL-frågor på det sättet. Det är någon som har skapat, om du vill, en liten motor att oavsett parametrarna kommer det att slänga ut lite SQL, och igen, att SQL inte nödvändigtvis kommer att vara effektiv SQL.
Då tänkte jag att jag skulle nämna impedansmatchningen, de data som programmerare använder är annorlunda än de data som de sorterar. Så, våra DMS lagrar data i tabeller, organiserade den objektorienterade koden är mestadels kodare, programmerar objektorienterad form idag och de beställer data i objektsstrukturer, så det kartlägger inte det ena till det andra. Så det finns en nödvändighet att översätta från vad programmeraren tror att uppgifterna är till vad databasen tycker vad uppgifterna är. Det verkar som om vi måste ha gjort något fel för att det ska vara fallet. SQL har DDL för datadefinition, det har DML - datahanteringsspråk - välj, projicera och gå med för att få den informationen. Nu finns det väldigt lite matematik och väldigt lite tidsbaserat grejer, så det är det ofullkomliga språket, även om det måste sägas att det har utökats och fortsätter att utvidgas.
Och sedan får du SQL-barriärproblemet, som alltid är rakare än diagrammet, i det att många människor ställde frågor av analytiska skäl, när de väl har fått svaret på frågeställningsvillkoren, vill ställa en annan fråga. Så det blir en dialogsak, ja, SQL byggdes inte för dialoger, den byggdes för att fråga vad du vill ha på en gång. Och det är ganska värt att veta det eftersom det finns vissa produkter där ute som faktiskt lämnar SQL för att möjliggöra konversation mellan användaren och data.
När det gäller databasprestanda - och denna typ av spridning till allting - ja, det finns CPU, det finns minne, det finns disk, det finns nätverkskostnader och det finns låsproblemet för mer än en person som vill ha exklusiv användning av data vid en given tidpunkt. Men det finns också dåliga SQL-samtal, det finns väldigt mycket som kan göras om du faktiskt optimerar SQL, vad gäller prestanda. Så, databasprestationsfaktorer: dålig design, dålig programdesign, samtidighet i arbetsbelastningen saknas, lastbalansering, frågestruktur, kapacitetsplanering. Det är datatillväxt. Och med några få ord är SQL bekvämt, men det optimerar inte själv.
Med det sagt tror jag att vi kan vidarebefordra till Rick.
Eric Kavanagh: Okej, Rick, låt mig ge dig nycklarna till WebEx-bilen. Ta bort det.
Rick Sherman: Okej, bra. Tack Robin, när vi började i början av presentationen är min grafik fortfarande ganska tråkig, men vi ska gå med det. Så jag håller med om allt som Robin talade om på SQL-sidan. Men vad jag nu vill koncentrera mig lite på är efterfrågan på data, som vi kommer att gå igenom mycket snabbt, utbudet som i verktyg som används i det utrymmet eller behovet av verktyg i det utrymmet.
Först och främst, det finns några i varje artikel som du läser har att göra med big data, massor av data, ostrukturerad data kommer från molnet, big data överallt som du kan tänka dig. Men tillväxten av databasmarknaden har ständigt varit med SQL, relationell databas antagligen från 2015, är fortfarande 95 procent av databasmarknaden. De tre främsta relationella leverantörerna har cirka 88 procent av marknadsandelen i det utrymmet. Så vi pratar fortfarande, som Robin talade, om SQL. Och faktiskt, även om vi tittar på Hadoop-plattformen, är Hive och Spark SQL - som min son, som är en datavetare, använder hela tiden nu - verkligen det dominerande sättet för människor att komma till data.
På databasesidan finns det nu två breda kategorier för användning av databaser. Det ena är för operativa databashanteringssystem, så företagsrelaterad planering, kundrelations bemanning så, Salesforce ERP, Oracle, EPIC, N4s, etc., i världen. Och det finns en stor mängd och expanderande mängd data som finns i datalager och andra affärsintelligensbaserade system. För att allt, oavsett var och hur det fångas, lagras eller genomförs, analyseras så småningom och det finns en enorm efterfrågan och ökning av användningen av databaser, särskilt relationella databaser ute på marknaden.
Nu har vi efterfrågan, vi har enorma mängder data som kommer. Och jag pratar inte riktigt bara om big data, jag talar om användningen av data i alla slags företag. Men åtföljer det från en försörjningssida, för människor som kan hantera dessa resurser, har vi först ut, vi har en slags brist på DBA. Vi har enligt Bureau of Labor Statistics, från 2014–2024 kommer DBA-jobb bara att växa med 11 procent - nu är det människor som har DBA-jobbtitlar, men vi kommer att prata om det på en sekund - kontra 40- plus procent årlig datatillväxtutrymme. Och vi har många DBA; i genomsnitt samma studie talade om medelåldern är ganska hög jämfört med andra IT-yrken. Och sedan har vi många människor som lämnar fältet, inte nödvändigtvis går i pension, utan byter till andra aspekter, går in i ledningen eller vad som helst.
En del av anledningen till att de lämnar är att DBA-jobbet blir allt hårdare. Först och främst har vi DBA som hanterar många olika databaser själva, fysiska databaser, som finns överallt, såväl som olika typer av databaser. Nu kan det vara relationellt, eller de kan vara andra databaser, databasstyper också. Men även om det är relationellt kan de ha någon av en, två, tre, fyra olika leverantörer som de faktiskt försöker hantera. DBA involveras vanligtvis efter designen av databasen eller applikationen. Robin talade om hur databaser eller applikationer blir designade, hur SQL blir designade. Tja, när vi pratar om datamodellering, ER-modellering, utökad ER-modellering, dimensioneringsmodellering, avancerad dimensionell modellering, vad som helst, typiskt applikationsprogrammerare och applikationsutvecklare designar med sitt slutmål i åtanke - de utformar inte för effektiviteten hos själva databasstrukturen. Så vi har mycket dålig design.
Nu talar jag inte om leverantörerna av kommersiella företagsapplikationer; de har vanligtvis ER-modeller eller utökade ER-modeller. Det jag talar om är att det finns mycket fler affärsprocesser och applikationer som byggs av applikationsutvecklare i alla företag - det är sådana som inte nödvändigtvis är utformade för effektivitet eller effektivitet vid implementering. Och själva DBA: erna är överarbetade och de har 24/7 ansvar ibland, de får allt fler databaser. Jag tror att det har gjort lite med att människor inte riktigt förstår vad de gör eller hur de gör det. Deras egen lilla grupp och människor fortsätter bara att tänka, ”Ja, alla dessa verktyg är bara så enkla att använda, vi kan bara fortsätta kasta på fler och fler databaser på deras arbetsbelastning, ” vilket inte är fallet.
Som leder oss till DBA på deltid och av misstag. Vi har IT-team som är små och de har inte nödvändigtvis råd med en dedikerad DBA. Det är nu sant för små till medelstora företag, där utvidgningen av databas- och databasapplikationer har exploderat under det senaste decenniet och fortsätter att expandera. Men det är också fallet med stora företag, som vanligtvis har gjort datalagring, analys av affärsintelligens under lång, lång tid. För länge sedan brukade vi få dedikerade DBA för dessa projekt; vi får aldrig en dedikerad DBA längre. Vi ansvarar för att utforma databasen, vilket är bra om det är någon som har erfarenhet. Men i allmänhet är DBA: er applikationsutvecklare, de tar ofta den rollen som en deltid i sitt jobb, de har inte formell utbildning i det och igen, de utformar det för sina slutmål, de är inte utforma den för effektivitet.
Och det är mycket skillnad mellan design och utveckling, kontra distribution och hantering. Så vi har det "öre kloka, pund dumt", med en liten spargris där, hoppar över att få de färdigheter och resurser som behövs i projekten. Tänker att alla kommer från "Revenge of the Nerds", min lilla bild där. Nu, så långt vad folk behöver, så har vi en utökad användning av databaser och data i SQL. Vi har begränsat antal DBA: er som är skickliga och experter på dessa inställningar och utformning och hantering och implementering situationer. Och vi har mer och mer DBA på deltid eller av misstag, människor som inte har haft den formella utbildningen.
Så, vad är några av de andra sakerna som också kommer in i frågan om att dessa databaser inte är inställda eller hanteras också? För det första antar många att databassystemet själva har tillräckliga verktyg för att hantera sig själva. Nu blir verktygen enklare och enklare att göra - design och utveckling - men det är annorlunda än att göra en bra design och god hantering, kapacitetsplanering, övervakning etc. för distribution. Så för det första antar människor att de har alla verktyg de behöver. För det andra, om du är en DBA på deltid eller av misstag, vet du inte vad du inte vet.
Jag antar att jag glömde en del av frasen där, så att de många gånger inte förstår vad de ens behöver titta på i designen eller när de hanterar eller använder databaserna. Om det inte är ditt yrke, kommer du inte att förstå vad du behöver göra. Den tredje är att SQL är ett go-to-verktyg, så Robin talade om SQL, och hur dåligt SQL ibland är konstruerat, eller ofta är konstruerat. Och även en av mina husdjur i BI-datalagring, datamigrering, datateknikutrymme är att människor snarare än att använda verktyg har en tendens att skriva SQL-kod, lagrade procedurer, även om de använder ett dyrt dataintegrationsverktyg eller ett dyrt BI-verktyg, de använder ofta det verkligen bara för att köra lagrade procedurer. Så att vikten av att förstå databasdesign, konstruktion av SQL blir ännu viktigare.
Och slutligen finns det denna silo-strategi, där vi har enskilda människor som tittar på enskilda databaser. De ser inte på hur applikationerna fungerar och interagerar med varandra. Och de tittar också ofta på databaser kontra applikationer som de använder dem för. Så arbetsbelastningen som du får i databasen är avgörande i designen, kritisk för att ställa in den, kritisk för att försöka ta reda på hur man planerar för kapacitet osv. Så när man tittar på skogen från träden är människor i ogräs, titta på enskilda tabeller och databaser och inte titta på den övergripande interaktionen mellan dessa applikationer i arbetsbelastningen.
Slutligen måste människor titta på de viktigaste områdena som de behöver titta på. När de planerar att hantera databaser måste de först tänka på, utveckla vissa applikationscentriska prestandametriker, så de måste titta på inte bara hur den här tabellen är strukturerad, hur den är särskilt modellerad, men hur används den? Så om du har företagsprogram som beror på hantering av leveranskedjan, om du tar order från webben, om du gör BI - vad du än gör - måste du titta på vem som använder det, hur de är använder den, vad volymerna är, när det kommer att hända. Det du verkligen försöker leta efter är väntetiderna, för oavsett vad, alla applikationer bedöms av hur lång tid det tar att få gjort något, vare sig det är en person eller bara utbyte av data mellan applikationer eller processorer. Och vad är flaskhalsarna? Så ofta när du försöker felsöka problem försöker du naturligtvis verkligen titta på vad som är de verkliga flaskhalsarna - inte nödvändigtvis hur du kan ställa in allt, men hur blir du av och flyttar prestandan upp på väntetiderna och genomströmning - vad du än behöver titta på.
Och du måste verkligen separera datafångsten, transaktionerna, transformationsaspekterna i databasen tillsammans med analysen. Var och en av dem har olika designmönster, var och en av dem har olika användningsmönster och var och en måste justeras på olika sätt. Så du måste tänka på hur denna information används, när den används, vad den används för och ta reda på vad prestandametriken och vilka nyckel saker du vill analysera relaterade till den användningen. När du nu tittar på att övervaka prestandan vill du titta på själva databasverksamheten. du vill titta på både datastrukturerna, så indexen, partitioneringen och andra fysiska aspekter av databasen, till och med databasens struktur - oavsett om det är ER-modell eller dimensionell modell, dock är den strukturerad - alla dessa saker har inverkan på prestanda, särskilt i olika sammanhang för datafångstanalys och de transformationer som sker.
Och som Robin nämnde på SQL-sidan är det kritiskt att titta på SQL som drivs av dessa olika applikationer i dessa databaser. Och titta på de övergripande applikationsbelastningarna och infrastrukturmiljön som dessa databaser och applikationer kör på. Så att nätverken, servrarna, molnet - oavsett vad de kör på - också tittar på effekterna som dessa applikationer och dessa databaser har inom det sammanhanget, har alla dessa samspel mellan att kunna ställa in databasen.
Och slutligen, när du tittar på verktyg, vill du kunna titta på de tre olika typerna av analyser relaterade till det. Du vill titta på beskrivande analys: vad som händer och var, relaterat till databasen och applikationsprestanda. Du vill ha förmågan att göra diagnostisk analys för att inte bara ta reda på vad som händer utan varför händer det, var är flaskhalsarna, var är problemen, vad fungerar bra, vad fungerar inte bra? Men att kunna analysera och undersöka problemområdena för att hantera dessa, antingen för design eller vad du behöver göra.
Och slutligen är den mest aggressiva eller proaktiva typen av analyser att faktiskt göra någon prediktiv analys, prediktiv analysmodellering, vad som helst. Vi vet att databasen och applikationerna fungerar i detta sammanhang, om vi ökar kapaciteten, om vi får fler användare, om vi gör mer genomströmning, vad vi än gör, att kunna projicera vad, hur och var det ska påverka databasen, applikationerna, gör att vi kan planera för och ta reda på proaktivt, var flaskhalsarna är, var väntetiderna kan drabbas och vad vi behöver göra för att fixa saker. Så vi vill ha verktyg som kan implementera prestandamätningarna, övervaka prestandan, liksom i dessa tre typer av analyser. Och det är min översikt.
Eric Kavanagh: Okej, låt mig överlämna det till - det är förresten två fantastiska presentationer - låt mig överlämna detta till Bullett Manale för att ta det därifrån. Och folk, glöm inte att ställa goda frågor; vi har redan bra innehåll. Ta bort den, Bullett.
Bullett Manale: Låter bra. Tack, Eric. Så mycket av vad Rick sa och Robin sa, jag håller uppenbarligen med 100 procent. Jag skulle säga att jag drog upp denna bild, för jag tror att den passar, jag vet inte för er som är "A-Team" fans redan på 80-talet, John Hannibal Smith hade ett ordstäv som han alltid skulle säga, "Jag älskar det när en plan samlas, " och jag tror att när du pratar om särskilt SQL-servern, där vi fokuserar, vilket är den produkt som vi kommer att prata om idag, SQL Diagnostic Manager, det är definitivt en av de saker du måste ha; du måste kunna utnyttja de uppgifter du har och kunna fatta beslut utifrån dessa uppgifter, och i vissa fall letar du inte efter ett beslut; du letar efter något för att berätta när något kommer att ta slut på resurser, när du kommer att ta slut på resurser, när du kommer att ha en flaskhals, sådana saker.
Det handlar inte bara om att övervaka en specifik metrisk. Så med Diagnostic Manager är en av de saker som det gör mycket bra att hjälpa dig när det gäller prognoser och förståelse specifikt för arbetsbelastningen och vi kommer att prata om mycket av det idag. Verktyget är inriktat på datahanteraren, DBA eller den fungerande DBA, så många saker som Rick nämnde om, den fungerande DBA är så sant. I många fall, om du inte är en DBA, kommer det att finnas många frågetecken som du kommer att ha när det är dags att hantera en SQL-miljö, saker du inte vet. Och så letar du efter något som hjälper dig, tar dig igenom processen och utbildar dig också i processen. Och så är det viktigt att verktyget du använder för sådana beslut kommer att ge dig lite inblick i orsakerna till att dessa beslut fattas, det säger inte bara "Hej, gör det här."
Eftersom jag är den fungerande DBA, så kan jag så småningom bli den fullständiga DBA med den verkliga expertisen och kunskapen för att backa den titeln. Så sagt när vi pratar om att vara databasadministratör - jag visar alltid den här bilden först, eftersom DBA har några olika roller och beroende på vilken organisation du är med kommer du att ha, de kommer att variera från en plats till en annan - men vanligtvis kommer du alltid att på något sätt ansvara för din lagring, din planering av den lagringen och förståelse för att förutse, jag skulle säga, hur mycket utrymme du ska att behöva, vare sig det är för dina säkerhetskopior eller om det är för databaserna själva. Du kommer att behöva förstå och bedöma det.
Dessutom kommer du att behöva kunna förstå och optimera saker efter behov, och när du går igenom miljöövervakningen är det uppenbart viktigt att du gör ändringar eftersom de behövs baserat på saker som förändring i själva miljön. Så, saker som antalet användare, saker som popularitet för applikationer, säsongsbetoningar i en databas, allt bör beaktas när du gör din prognos. Och då, självklart att titta på andra saker i termer av att kunna tillhandahålla rapporterna och den information som är nödvändig när det gäller att fatta dessa beslut. I många fall betyder det att göra jämförande analys; det innebär att du kan titta specifikt på en viss metrisk och förstå vad värdet på det metret har varit över tid, så att du kan förutse var det kommer att gå framåt.
Så vad mycket av verktyget Diagnostic Manager gör har dessa funktioner och människor använder det varje dag för att kunna göra saker som prognos, och jag har lagt definitionen här av kapacitetsplanering. Och det är en ganska bred och faktiskt ganska vag definition, som bara är processen att bestämma den produktionskapacitet som en organisation behöver för att möta de förändrade kraven på sina produkter, och i slutet av dagen är det verkligen vad det handlar om: Det är om att kunna ta information som du har på något eller annat sätt och ta den informationen och fatta beslut för att hjälpa dig att gå framåt när du går genom livscykeln för dina databaser. Och så, de typer av saker som är orsakerna till att människor behöver göra detta är uppenbarligen först och främst, i de flesta fall, för att spara pengar. Företagen är uppenbarligen deras huvudmål att tjäna pengar och spara pengar. Men i processen tillsammans med det betyder det också att du kan se till att din driftstopp inte finns någon driftstopp. Och att kunna se till att du mildrar alla chanser att drifttid inträffar, så att hålla det från att hända till att börja med, med andra ord, inte vänta på att det ska hända och sedan reagera på det.
Förutom att generellt kunna öka produktiviteten för dina användare, att göra dem mer effektiva så att du kan få mer affärer är uppenbarligen nyckeln här, så det är dessa typer av saker som DBA eller någon som är involverade i prognos eller kapacitet planering kommer att behöva kunna vada igenom informationen för att kunna fatta dessa beslut. Och totalt sett kommer detta uppenbarligen att hjälpa dig att eliminera avfall, inte bara avfall i form av pengar, utan också när det gäller tid och i termer av generellt resurser som kan användas för andra saker, eventuellt. Så att kunna eliminera det avfallet så att du inte har möjlighetskostnader som är bundna till själva avfallet.
Så, med det sagt, vilka är de typer av frågor som vi får, specifika för personen som är en DBA? När ska jag ta slut på rymden? Det är en stor, inte bara hur mycket utrymme jag förbrukar nu, men när ska jag ta slut, baserat på trenderna och tidigare historia? Samma sak med de faktiska förekomsten av SQL, databaserna, vilka servrar kan jag konsolidera? Jag tänker lägga på några av VM: erna, vad är vettigt när det gäller vilka databaser jag ska konsolidera och vilka instanser av SQL ska de ligga på? Alla dessa typer av frågor måste kunna besvaras. För i de flesta fall, om du är en DBA eller agerar DBA, kommer du att konsolidera det någon gång i din karriär. I många fall kommer du att göra det fortlöpande. Så du måste kunna fatta dessa beslut snabbt, inte spela gisselspel när det gäller det.
Vi pratade om flaskhalsar och var de kommer att inträffa nästa, att kunna förutse det, än en gång, istället för att vänta på att de skulle hända. Så, naturligtvis, alla dessa saker vi pratar om, är vettiga i den meningen att du litar på historisk data, i de flesta fall, för att kunna generera dessa rekommendationer, eller i vissa fall kunna formulera beslut själv, för att kunna komma med dessa svar. Men det påminner mig om att när du hör radioannonserna för någon som säljer värdepapper eller något liknande, är det alltid "tidigare resultat är inte en indikation på framtida resultat" och sådana saker. Och samma sak gäller här. Du kommer att ha situationer där dessa prognoser och dessa analyser kanske inte är 100 procent rätt. Men om du har att göra med saker som har hänt i det förflutna och det kända, och att kunna ta och göra "vad om" med många av dessa typer av frågor, du kommer att stöta på, är mycket värdefullt och det kommer att få dig mycket längre än att spela gissespelet.
Så, dessa typer av frågor uppenbarligen kommer de att komma upp, så hur vi hanterar många av dessa frågor med Diagnostic Manager, för det första har vi prognosmöjligheter, att kunna göra detta i databasen, vid bordet också som enhet eller volym. För att inte bara kunna säga, "Hej, vi är fulla av utrymme", utan sex månader från och med nu, två år från och med nu, fem år från och med nu, om jag budgeterar för det, hur mycket körutrymme ska jag att behöva budgetera för? Det är frågor jag kommer att behöva ställa, och jag kommer att behöva kunna använda någon metod för att göra det snarare än att gissa och sätta fingret upp i luften och vänta på att se hur vinden blåser, vilket är många gånger, tyvärr, hur många av dessa beslut fattas.
Utöver det, att kunna - ser ut som min bild glider av det lite - men att kunna ge lite hjälp i form av rekommendationer. Så det är en sak att kunna visa dig en instrumentbräda full av mätvärden och kunna säga, "OK, här är alla mätvärden och var de är på, " men sedan för att kunna göra några eller ha lite förståelse för vad man ska göra, baserat på det är ännu ett steg. Och i vissa fall är folk tillräckligt utbildade i rollen som DBA för att kunna fatta dessa beslut. Och så har vi några mekanismer i verktyget som hjälper till med det, som vi visar dig på bara en sekund. Men att kunna visa inte bara vad rekommendationen är, utan också ge viss inblick i varför den rekommendationen görs och sedan också ovanpå, i vissa fall faktiskt kunna komma med ett skript som automatiserar Åtgärd av denna fråga är också idealisk.
Att gå vidare till nästa här, som vi ser, det är bara generellt sett att förstå ner till metrisk nivå vad som är normalt. Jag kan inte berätta vad som inte är normalt om jag inte vet vad som är normalt. Och så, genom att ha något sätt att mäta det som är nyckeln och du måste kunna ta hänsyn till flera typer av områden, till exempel - eller jag skulle säga tidsramar - olika grupper av servrar, att kunna göra detta dynamiskt, från ett alarmerande perspektiv, med andra ord, mitt på natten, under mitt underhållsfönster, förväntar jag mig att min CPU ska köras med 80 procent baserat på allt underhåll som pågår. Så jag kanske vill öka mina trösklar högre, under dessa tidsramar kontra kanske mitt på dagen, när jag inte har så mycket aktivitet.
Det är några saker som uppenbarligen kommer att vara miljömässiga, men saker som du kan använda på det som hanteras, för att kunna hjälpa dig att hantera den miljön mer effektivt och göra det lättare att göra det. Det andra området är uppenbarligen att kunna helt enkelt ge rapporter och information för att kunna svara på dessa typer av "vad om" -frågor. Om jag just har gjort en förändring av min miljö, vill jag förstå vad den påverkan har varit, så att jag kan tillämpa samma förändring på andra instanser eller andra databaser i min miljö. Jag vill kunna ha lite information eller lite ammunition för att kunna göra den förändringen med viss sinnesfrid och veta att det kommer att bli en bra förändring. Så att kunna göra den jämförande rapporteringen, kunna rangordna mina förekomster av SQL, kunna rangordna mina databaser mot varandra, att säga, "Vilken är min högsta konsument av CPU?" Eller vilken som tar längst i villkor för väntningar och liknande? Så mycket av den informationen kommer också att finnas tillgänglig med verktyget.
Och så, sist men inte minst, är bara en övergripande förmåga att du behöver ett verktyg som kommer att kunna hantera vilken situation som kommer på din väg, och så vad jag menar med det är om du har en stor miljö med en I många fall kommer du förmodligen att stöta på situationer där du behöver dra statistik som traditionellt inte är mätvärden som en DBA skulle vilja till och med övervaka i vissa fall, beroende på den specifika situationen. Så att ha ett verktyg som du kan, det är utdragbart, för att kunna lägga till ytterligare mätvärden och kunna använda dessa mätvärden i samma form och på samma sätt som du skulle använda dem om du använde en out-of-the-box metrisk, till exempel. Så att kunna köra rapporter, kunna varna, baslinjen - alla saker vi pratar om - är också en viktig del av att kunna göra denna prognos och göra det så att du får svar du letar efter kunna fatta dessa beslut och gå vidare.
Nu som Diagnostic Manager gör detta har vi en centraliserad tjänst, en grupp tjänster som kör, samlar in data från 2000 till 2016-instanser. Och vad vi gör är att vi tar den informationen och vi lägger in dem i ett centralt arkiv och vad vi gör med dessa uppgifter, uppenbarligen, är att vi gör mycket för att kunna ge ytterligare insikt. Nu, förutom det - och en av de saker som inte är här - har vi också en tjänst som kör mitt på natten, som är vår prediktiva analystjänst, och som gör en del knasande och det hjälper till att förstå och hjälpa dig som DBA eller fungerande DBA, att kunna göra dessa typer av rekommendationer, för att också kunna ge viss insikt när det gäller baslinjer.
Så vad jag skulle vilja göra, och detta är bara ett snabbt exempel på arkitekturen, det stora takeaway här är att det inte finns några agenter eller tjänster som faktiskt sitter på de instanser du hanterar. Men vad jag skulle vilja göra är att bara ta dig in till ansökan här och ge dig en snabb demo. Och låt mig bara gå ut och låta det hända. Så låt mig veta, jag tror Eric, kan du se det OK?
Eric Kavanagh: Jag har det nu, ja.
Bullett Manale: OK, så jag ska ta dig igenom några av dessa olika delar som jag talade om. Och låt oss i princip börja med den typ av saker som är mer i linje med här är något du behöver göra, eller här är något som är en tidpunkt i framtiden och vi kommer att ge dig lite inblick i det. Och detta är att kunna verkligen förutse - eller jag skulle säga dynamiskt förutse - saker som de händer. När det gäller rapporter är en av de saker vi har i verktyget tre olika prognosrapporter. Och i fallet med en databasprognos, vad jag förmodligen skulle göra i situationen med att kunna förutse storleken på en databas över en tid, och jag ska bara ge dig ett par exempel på det . Så jag kommer att ta min revisionsdatabas, som är ganska I / O-intensiv - det finns mycket data som kommer till det. Vi har, låt oss se, vi gör det här här, och låt oss bara välja vårddatabasen här uppe.
Men poängen är att jag inte bara ser vad utrymmet är på det här, jag kan säga: "Titta, låt oss ta det senaste värdet av data" - och jag kommer att fibra här lite, Jag har inte riktigt ett års värde, jag har ungefär två månaders data - men eftersom jag väljer ett urval av månader här, kommer jag att kunna förutse eller förutse i detta i fallet de nästa 36 enheterna eftersom vår samplingsfrekvens är inställd på månader - det vill säga en enhet är en månad - och sedan skulle jag kunna, för att sedan driva en rapport för att i princip visa mig var vi skulle förutse vår framtida tillväxt, för dessa tre databaser. Och vi kan se att vi har en varierande grad av skillnad, eller varians, mellan de tre olika databaserna, särskilt vad gäller mängden data de konsumerar historiskt.
Vi kan se datapunkterna här representera historiska data, och sedan kommer linjen att ge oss prognosen, tillsammans med siffrorna för att säkerhetskopiera det. Så vi kan göra det på bordnivå, vi kan göra det även på enhetsnivån, där jag kan förutse hur stora mina enheter kommer att bli, inklusive monteringspunkter. Vi skulle kunna förutse samma typ av information, men återigen, beroende på urvalshastigheten, kommer jag att kunna bestämma hur många enheter och var vi tar vad vi vill förutspå. Lägg märke till att vi har olika typer av prognostyper. Så du får många alternativ och flexibilitet när det är dags att göra prognoser. Nu är det en sak vi kommer att göra, genom att faktiskt ge dig ett specifikt datum och kunna säga "Hej på det här datumet, det är här vi skulle förutse att tillväxten av dina data kommer att vara." Utöver detta kan vi dock förse dig med andra insikter som är relaterade till en del av analysen som vi utför under ledighetstiden och tjänsten när den körs. Några av de saker det gör, är att det försöker förutse de saker som troligen kommer att hända, baserat på historien om när saker hände i det förflutna.
Så vi kan se här, faktiskt, en prognos ger oss lite insikt i sannolikheten för att vi får problem under kvällen baserat på saker som återigen har hänt tidigare. Så uppenbarligen är detta bra, särskilt om jag inte är en DBA, jag kan titta på dessa saker, men vad som är ännu bättre om jag inte är en DBA, är denna analysflik. Så innan detta var här i verktyget skulle vi gå igenom och visa produkten för människor och de skulle vara "Det är fantastiskt, jag ser alla dessa nummer, jag ser allt, men jag vet inte vad jag ska göra" (skrattar) "Som ett resultat av det." Och så det vi har här är ett bättre sätt för dig att kunna förstå, om jag ska vidta åtgärder för att hjälpa till med prestanda, om jag kommer att vidta åtgärder till och med hjälper till med hälsan i min miljö, att kunna ha ett rankat sätt att tillhandahålla dessa rekommendationer, samt användbara tips i information för att lära mig mer om dessa rekommendationer och faktiskt ha även externa länkar till några av dessa data, som kommer att visa mig och ta mig till skälen till att dessa rekommendationer görs.
Och i många fall att kunna tillhandahålla ett skript som automatiserar, som sagt, saneringen av dessa problem. Nu är en del av vad vi gör här med den här analysen - och jag visar dig när jag går in för att konfigurera egenskaperna för den här instansen, och jag går till analyskonfigurationsavsnittet - vi har många olika kategorier som är listade här, och en del av det har vi indexoptimering och frågaoptimering. Så vi utvärderar inte bara själva statistiken och sådant, utan också saker som arbetsbelastningen och indexen. I det här fallet gör vi faktiskt några ytterligare hypotetiska indexanalyser. Så det är en av de situationer där jag inte vill, i många fall vill jag inte lägga till ett index om jag inte behöver. Men vid någon tidpunkt finns det en slags tipppunkt, där jag säger: ”Tja, tabellen börjar bli storleken eller de typer av frågor som körs inom arbetsbelastningen är vettigt nu att lägga till ett index. Men det hade inte varit vettigt kanske sex veckor innan. Så detta gör att du dynamiskt får den insikten om saker som, som sagt, kommer att förbättra prestanda baserat på vad som händer i miljön, vad som händer inom arbetsbelastningen, och gör sådana saker.
Och så får du mycket bra information här, såväl som möjligheten att optimera dessa saker automatiskt. Så det är ett annat område där vi skulle kunna hjälpa till, vad gäller vad vi kallar prediktiv analys. Nu, förutom det, skulle jag säga, vi har också andra områden som jag tror helt enkelt lånar sig hjälpa dig att fatta beslut. Och när vi pratar om att fatta beslut, återigen att kunna titta på historiska data, ge lite insikt för att få oss dit vi behöver vara för att förbättra prestandan.
En av de saker vi kan göra är att vi har en baslinjevisualisator som gör att vi selektivt kan välja vilket mätvärde vi vill - och låt mig hitta en anständig här - jag ska använda SQL CPU-användning, men poängen är att du kan gå tillbaka över hur många veckor som helst för att måla dessa bilder så att du kan se när dina utflykter är, för att se i allmänhet var det värdet faller inom de tidsperioder som vi har samlat in data. Och sedan kommer du också att märka att när vi går ut till själva instansen har vi möjligheten att konfigurera våra baslinjer. Och baslinjerna är en väldigt viktig del om att kunna automatisera saker och att kunna få information om saker. Och utmaningen, som de flesta DBA: er skulle säga, är att din miljö inte alltid är densamma under hela dagen, mot kvällen och vad som vi nämnde tidigare i exemplet med underhållsperioderna, när vi har höga nivåer av CPU eller vad som än händer.
Så i fallet här, med dessa faktiska baslinjer, kan vi ha flera baslinjer, så jag kanske har en baslinje till exempel, det är under mina underhållstimmar. Men jag kunde lika enkelt skapa en baslinje för mina produktionstimmar. Och poängen med att göra det är när vi går in i ett exempel på SQL och faktiskt har dessa flera baslinjer, då skulle vi kunna förutse och kunna utföra någon typ av automatisering, någon typ av sanering eller bara varna i allmänhet, annorlunda specifikt för tidens fönster. Så en av de saker du ser här är att dessa baslinjer som vi genererar använder historiska data för att tillhandahålla den analysen, men ännu viktigare, jag kan ändra dessa trösklar statiskt, men jag kan också automatisera dessa dynamiskt också. Så när underhållsfönstret, eller jag skulle säga att underhållsgränssnittets fönster dyker upp, skulle dessa trösklar automatiskt växla specifikt till de belastningar som jag stöter på under det här fönstret, kontra kanske mitt på dagen när mina belastningar är inte lika mycket, när arbetsbelastningen inte är lika inverkande.
Så det är något annat att tänka på när det gäller baslinjen. Uppenbarligen kommer dessa att vara riktigt användbara för dig, när det gäller att förstå vad som är normalt och att också kunna förstå, engagera när du också kommer att ta slut på resurser. Nu, den andra typen av saker som vi har i verktyget, som kommer att hjälpa dig att fatta beslut, dessutom är baslinjen och att kunna ställa in varningar runt dessa baslinjer och trösklarna som du skapar dynamiskt, som jag sa tidigare, bara att kunna köra ett stort antal rapporter som hjälper mig svara på frågor om vad som händer.
Så som ett exempel, om jag hade 150 instanser jag klarar av - i mitt fall gör jag inte det, så vi måste spela låtsas-spelet här - men om jag hade alla mina produktionsinstanser och jag behövde förstå var är det område som jag behöver uppmärksamhet på, med andra ord, om jag bara kommer att ha en begränsad tid att utföra någon typ av administration för att förbättra prestandan, vill jag fokusera på nyckelområdena. Och så, med det sagt, skulle jag kunna säga, "Baserat på den miljön, rangordna mina instanser mot varandra och ge mig den rankningen efter tvistpipa." Så oavsett om det är diskanvändning, minnesanvändning, om det väntar, Oavsett om det är responstid, kan jag korrelera - eller jag ska säga rang - dessa instanser mot varandra. Självklart är instansen som är överst på varje lista, om det är samma instans, det är förmodligen något jag verkligen vill fokusera på, för det är uppenbarligen en gång högst upp på listan.
Så du har många rapporter i verktyget som hjälper dig när det gäller att ranka miljön på instansnivå; du kan göra det också på databasnivå, där jag kan rangordna mina databaser mot varandra. Speciellt för trösklar och områden som jag kan ställa in kan jag till och med ställa in jokertecken här om jag vill, för att bara fokusera på vissa databaser, men poängen är att jag kan jämföra mina databaser på samma sätt. Också för andra typer av jämförande analyser och den stora i detta verktyg är den baslinjeanalys som vi har. Så om du bläddrar ner till servicevyn här ser du att det finns en statistikrapport om baslinjen. Nu kommer den här rapporten uppenbarligen att hjälpa oss att förstå inte bara de metriska värdena, utan för en specifik instans skulle jag kunna gå ut, och för någon av dessa mätvärden, faktiskt kunna titta på baslinjerna för dessa mätvärden.
Så, vad det än skulle vara, i procent eller vad jag än kunde gå ut och säga, "Låt oss se baslinjen för detta utbruten under de senaste 30 dagarna, " i vilket fall kommer det att visa mig de verkliga värdena jämfört med baslinjen och Jag skulle naturligtvis kunna fatta några beslut med den informationen, så det är en av dessa situationer, där det kommer att bero på vilken fråga det är, som du ställer vid den tiden. Men detta kommer uppenbarligen att hjälpa dig för många av dessa frågor. Jag önskar att jag kunde säga att vi hade en rapport som gör allt, och det är på samma sätt som den enkla rapporten, där du trycker på och knappen och det svarar bara på alla "vad om" -frågor du någonsin skulle kunna besvara. Men verkligheten är att du kommer att ha många attribut och många alternativ för att kunna välja mellan i dessa neddragningar för att kunna formulera dessa "vad om" -typfrågor som du letar efter .
Så många av dessa rapporter är inriktade på att kunna svara på dessa typer av frågor. Och så är det väldigt viktigt också att dessa rapporter och dessutom alla saker som vi redan har visat dig i verktyget, som jag nämnde tidigare, har flexibilitet att införliva nya mätvärden, hanteras, till och med kunna skapa räknare, eller SQL-frågor som är integrerade i dina omröstningsintervall, för att kunna hjälpa mig att svara på dessa frågor, att du kanske inte har förväntat oss att övervaka kan du lägga till det. Och du skulle kunna göra alla samma saker som jag just visade dig: baslinjen, köra rapporter och skapa rapporter från den metriken och kunna svara och göra många av dessa olika typer av saker som jag visar dig här.
Nu, utöver det - och en av de saker som vi uppenbarligen har stött på ganska mycket på senare tid - var det först, alla som bläddrar eller byter till VM. Och nu har vi många människor som är på väg till molnet. Och det finns en massa frågor som dyker upp om den typen av saker. Har det vettigt för mig att flytta till molnet? Ska jag spara pengar genom att flytta till molnet? Om jag skulle lägga dessa saker på en VM, på en maskin med delade resurser, hur mycket pengar kan jag spara? Dessa typer av frågor kommer uppenbarligen också att komma upp. Så många av de sakerna tänker på, med Diagnostic Manager kan vi lägga till och dra från de virtualiserade miljöerna i både VMware och Hyper-V. Vi kan också lägga till instanser som är ute på molnet, så att dina miljöer som till exempel Azure DB, eller till och med RDS, kan vi också ta ut statistik från dessa miljöer.
Så det finns mycket flexibilitet och mycket att kunna svara på dessa frågor eftersom det rör de andra typer av miljöer som vi ser människor på väg till. Och det finns fortfarande många frågor kring det här, och när vi ser att folk konsoliderar de miljöerna kommer de att behöva kunna svara på dessa frågor också. Så det är en ganska bra översikt, säger jag, om Diagnostic Manager, eftersom det gäller detta ämne. Jag vet att ämnet för affärsintelligens kom upp och att vi också har ett verktyg för affärsintelligens som vi inte pratade om idag, men det kommer också att ge dig insikt i fråga om att besvara dessa typer av frågor när det gäller din kuber och alla dessa olika typer av saker också. Men förhoppningsvis har detta varit en bra översikt, åtminstone när det gäller hur denna produkt kan hjälpa till att kunna formulera en bra plan.
Eric Kavanagh: Okej, bra grejer. Ja, jag slänger det till Rick, om han fortfarande är ute. Rick, några frågor från dig?
Rick Sherman: Ja, så först, det här är jättebra, jag gillar det. Jag gillar särskilt utvidgningen till VM och moln. Jag ser att många apputvecklare tror att om det är i molnet så behöver de inte ställa in det. Så-
Bullett Manale: Rätt, vi måste fortfarande betala för det, eller hur? Du måste fortfarande betala för vad det än är som folk sätter på molnet, så om det fungerar dåligt, eller om det orsakar mycket CPU-cykler, är det mer pengar du måste betala, så det är det inte, du behöver fortfarande mäta det här, absolut.
Rick Sherman: Ja, jag har sett en hel del dåliga mönster i molnet. Jag ville fråga, skulle den här produkten också användas - jag vet att du nämnde BI-produkten och att du har massor av andra produkter som interagerar med varandra - men skulle du börja titta på SQL-prestanda, enskilda frågor i det här verktyget? Eller skulle det vara andra verktyg som skulle användas för det?
Bullett Manale: Nej, det skulle absolut. Det är en av de saker som jag inte täckte och som jag tänkt på, är frågorna i den. Vi har många olika sätt att identifiera frågeställningar, oavsett om det är relaterat till, specifikt till väntningar som vi ser i den här vyn här, eller om det är relaterat till resursförbrukningen av frågor totalt sett, det finns ett helt antal sätt att analysera frågan prestanda. Det är om det är längd, CPU, I / O, och än en gång kan vi också titta på själva arbetsbelastningen för att ge lite insikt. Vi kan ge rekommendationerna i analysavsnittet och vi har också en webbaserad version som ger information kring själva frågorna. Så jag kan få rekommendationer om saknade index och förmågan att se exekveringsplanen och allt det där; Det är också en kapacitet också. Så absolut kan vi diagnostisera frågor på sju sätt till söndag (skrattar) och kunna ge den insikt i fråga om antalet avrättningar, vare sig det är resursförbrukning, väntan, varaktigheten, allt så bra grejer.
Rick Sherman: OK, bra. Och vad är då belastningen på själva instanserna med all denna övervakning?
Bullett Manale: Det är en bra fråga. Utmaningen med att besvara den frågan är, är det beror, det är precis som allt annat. Mycket av vad vårt verktyg har att erbjuda, det ger flexibilitet och en del av den flexibiliteten är att du får berätta vad man ska samla in och vad man inte ska samla in. Så till exempel med själva frågorna behöver jag inte samla in väntinformationen, eller det kan jag också. Jag kan samla in information relaterad till frågor som överträffar en tidsperiod, av körning Som ett exempel på det, om jag skulle gå in på konfigurationsfrågorna och jag skulle säga, "Låt oss ändra detta värde till noll", är verkligheten att bara i princip gör att verktyget samlar in alla frågor som körs och det är verkligen inte anda av varför det är där, men generellt sett skulle jag kunna göra det om jag ville tillhandahålla ett fullständigt urval av data för alla frågor.
Så det är mycket relativt vad dina inställningar generellt sett är ur rutan. Det är allt från cirka 1–3 procent omkostnader, men det finns andra villkor som kommer att gälla. Det beror också på hur mycket portfrågor som körs i din miljö, eller hur? Det beror också på metoden för insamling av dessa frågor och vilken version av SQL det är. Så till exempel, SQL Server 2005, kommer vi inte att kunna dra från utökade händelser, medan vi skulle dra från ett spår för att göra det. Så, det skulle vara lite annorlunda i fråga om hur vi skulle gå till att samla in dessa data, men som sagt, som jag sa, har vi funnits sedan jag antar sedan 2004 med den här produkten. Det har pågått länge, vi har tusentals kunder, så det sista vi vill göra är att ha ett prestationsövervakningsverktyg som orsakar prestandaproblem (skrattar). Och så vi försöker undvika det så mycket som möjligt, men generellt sett är ungefär 1-3 procent en bra tumregel.
Rick Sherman: OK, och det är ganska lågt, så det är fantastiskt.
Eric Kavanagh: Bra. Robin, några frågor från dig?
Robin Bloor: Jag är ledsen, jag var på stum. Du har en flera databasfunktioner, och jag är intresserad av hur du kan titta på flera databaser och därför kan du veta att en större resursbas kan delas upp mellan olika virtuella maskiner och så vidare. Jag är intresserad av hur människor faktiskt använder det. Jag är intresserad av vad kunderna gör med det. För det ser ut för mig, det är säkert, när jag krossade med databaser, något jag aldrig haft till hands. Och jag skulle bara överväga en instans på något meningsfullt sätt vid en viss tidpunkt. Så, hur använder människor detta?
Bullett Manale: Generellt sett talar du om bara själva verktyget? Hur använder de det? Jag menar, generellt, det handlar om att kunna ha en central punkt i närvaro av miljön. Ha sinnesfrid och vet att om de stirrar på en skärm och ser grönt, vet de att allt är bra. Det är när problem händer och uppenbarligen de flesta fall från en DBA: s perspektiv, många gånger händer dessa problem när de är framför konsolen, så att de kan bli meddelade så snart problemet händer. Men utöver det, att kunna förstå när problemet händer, att kunna komma till hjärtat av informationen som ger dem ett visst sammanhang i termer av varför det händer. Och så är det, tror jag, den största delen: att vara aktiv med det, inte vara reaktiv.
De flesta DBA som jag pratar med - och jag vet inte, det är en bra procentandel av dem - tyvärr är de fortfarande i den reaktiva typen av miljö; de väntar på att en konsument ska kontakta dem för att säga att det finns ett problem. Och så ser vi många människor försöka bryta sig loss från det och jag tror att det är en stor del av anledningen till att människor gillar det här verktyget är att det hjälper dem att vara proaktiva men det ger dem också inblick i vad som händer, vad är problemet, men i många fall, vad vi hittar åtminstone - och kanske är det bara DBA som berättar för oss detta - men DBA: er, uppfattningen är att det alltid är deras problem, även om det är applikationsutvecklaren som skrev applikationen som inte skrev det ordentligt, det är de som kommer att ta skylden, för de tar den applikationen in i sina system eller servrar och sedan när resultatet är dåligt pekar alla på DBA: "Hej, det är ditt fel."
Så det här verktyget kommer många gånger att användas för att hjälpa till att göra fallet för DBA att säga, "Hej, det är här problemet ligger och det är inte jag." (Skrattar) Vi måste förbättra detta, oavsett om det är att ändra frågorna eller vad det än kan vara. I vissa fall kommer det att falla i deras hink när det gäller deras ansvar, men åtminstone att ha verktyget för att kunna hjälpa dem att förstå det och vet det, och att göra det på ett snabbt sätt är uppenbarligen den ideala metoden.
Robin Bloor: Ja, de flesta webbplatser som jag är bekant med, men det har gått ett tag sedan jag har varit ute och tittat på olika multidatabaser, men mest vad jag brukade hitta var att det skulle vara DBA som fokuserade på en handfull databaser. Och det skulle vara databaserna, att om de någonsin gick ner skulle det vara ett riktigt stort problem för företaget, och så vidare. Och de andra, de kommer bara att samla in statistik då och då för att se att de inte slutade utrymme och de skulle aldrig titta på dem alls. Och medan du gjorde demot såg jag på det här och jag tänkte väl, på ett eller annat sätt utökar du, bara genom att tillhandahålla något liknande för databaser som ofta var, ingen brydde sig för mycket om, för de har datatillväxt, de har tillväxt också ibland också. Du utökar DBA-täckningen på ett ganska dramatiskt sätt. Så det är vad frågan egentligen handlar om, är det att med en uppsättning verktyg som detta, kan du i slutändan kunna ge en DBA-tjänst till varje databas som finns i företagets nätverk?
Bullett Manale: Visst, jag menar, utmaningen är att det är som du sa ganska vältaligt, är som att det finns några databaser som DBA bryr sig om och sedan finns det några som de inte bryr sig om så mycket. Och det sätt som den här produkten, det är licensierad är per instansbasis. Så det finns, antar jag, du skulle säga, en tröskel för när människor bestämmer "Hej, detta är inte en tillräckligt kritisk instans att jag vill hantera det med det här verktyget." Som sagt, det finns andra verktyg som vi gör har det är mer, antar jag, att tillgodose de mindre viktiga fallen av SQL. En av dem skulle vara som Inventory Manager, där vi gör lätta hälsokontroller mot instanserna, men utöver det vi gör är att vi upptäcker, så vi identifierar nya instanser som har tagits online och sedan, från den punkten, som DBA kan jag säga, ”OK, här är en ny instans av SQL, nu är det Express? Är det gratisversionen eller är en företagsversion? ”Det är förmodligen en fråga jag vill ställa mig själv, men för det andra, hur viktigt är den instansen för mig? Om det inte är så viktigt, kanske jag har det här verktyget att gå ut och göra det, generiskt, vad jag skulle kalla generiska hälsokontroller i den meningen att det är de elementära typerna av saker jag bryr mig om som en DBA: Är enheten att fylla ? Svarar servern på problem? De viktigaste sakerna, eller hur?
Medan Diagnostic Manager, det verktyg som jag bara visade dig, kommer det att gå ner till fråganivån, det kommer att komma ner i rekommendationen från index, titta på exekveringsplanen och allt det där bra, medan det huvudsakligen är fokuserat på vem som äger vad, vad är det som jag äger och vem ansvarar för det? Vilka servicepaket och hot fixes har jag? Och kör mina servrar med huvudingredienserna i det jag anser vara en hälsosam instans av SQL? Så för att svara på din fråga, det är lite av en blandning. När vi har människor som tittar på det här verktyget tittar de vanligtvis på en mer kritisk uppsättning instanser. Som sagt, vi har några människor som köper varje instans som de har och hanterar det, så det beror bara. Men jag säger er, totalt sett finns det definitivt en tröskel för de människor som anser att deras miljö är tillräckligt viktig för att ha ett verktyg som detta för att hantera dessa instanser.
Robin Bloor: Okej, en annan fråga innan jag överlämnar den till Eric. Intrycket man får, bara genom att titta på branschen är att databaser fortfarande har en livslängd, men all data hälls ut i alla dessa dataljöer och så vidare. Det är egentligen hype, och hype återspeglar aldrig verkligheten, så jag är intresserad av vilken typ av verklighet du upplever där ute? Är de viktiga databaserna inom en organisation, upplever de den traditionella datatillväxten, som jag brukade tänka på som 10 procent per år? Eller växer de mer än så? Gör stor data att göra dessa databaser ballong? Vad är den bild du ser?
Bullett Manale: Jag tror att många fall vi ser att vissa data flyttas in i de andra segmenten där det är mer meningsfullt när det finns andra tekniker som blir tillgängliga. Som nyligen, några av de större data grejer. Men dessa databaser, skulle jag säga, är det svårt att generalisera i många fall eftersom alla är lite annorlunda. Generellt sett ser jag dock en viss skillnad. Som jag sa, människor flyttar till de elastiska modellerna i många fall eftersom de vill växa resurserna och inte så mycket på andra områden. Vissa människor flyttar till big data. Men det är svårt att få en känsla för, säger du, uppfattningen, eftersom de människor jag pratar med i allmänhet har traditionella databaser och använder detta i en SQL Server-miljö.
Som sagt, jag skulle säga när det gäller SQL själv, jag tror definitivt fortfarande att den får marknadsandelar. Och jag tror att det finns många människor som fortfarande är på väg mot SQL från andra platser som Oracle, eftersom det är mer överkomligt och verkar vara uppenbart, eftersom SQL-versioner blir mer avancerade - och du ser detta med de senaste sakerna som pågår med SQL, vad gäller kryptering och alla andra funktioner som gör det till en miljö eller en databasplattform - det är uppenbarligen mycket uppdragskritiskt kapabelt, antar jag. Så jag tror att vi ser det också. Där du ser ett skifte sker det fortfarande. Jag menar, det hände för tio år sedan, det är fortfarande, tror jag, att det händer i termer av SQL Server, där miljön växer och marknadsandelen växer.
Robin Bloor: OK, Eric, jag antar att publiken har en fråga eller två?
Eric Kavanagh: Ja, låt mig kasta en snabb till dig. Det är faktiskt en ganska bra fråga. En av de deltagande frågar, kommer det här verktyget berätta om en tabell kan behöva ett index för att påskynda frågan? Om så är fallet, kan du visa ett exempel?
Bullett Manale: Ja, så jag vet inte om jag har en för att specifikt lägga till ett index, men du kan se här, vi har fragmenteringsrekommendationer här. Jag tror också att vi just har haft och detta var en del av Diagnostic Manager som erbjuder den webbaserade versionen, där det säger att jag har ett saknat index. Och vi kan se dessa rekommendationer och det kommer att berätta för oss den potentiella vinsten genom att indexera den informationen. Det andra jag bara vill nämna är att när vi gör rekommendationerna kommer manuset att byggas för det för många av dessa. Att man inte är ett bra exempel, men du skulle kunna se, ja, situationerna där ett index - antingen ett duplikatindex eller tillägg av ett index - skulle förbättra prestandan, och som jag sa tidigare gör vi mycket av det genom hypotetisk indexanalys. Så det hjälper verkligen när det gäller att förstå arbetsbördan, att kunna tillämpa det på rekommendationen.
Eric Kavanagh: Det är bra grejer, och det här kommer att ge mig en bra del av de sista kommentarerna här. Robin och jag och Rick också, har hört under många år nu, det är prat om självjusterande databaser. Det är en självinställningsdatabas! Allt jag kan säga er att: tro inte på dem.
Bullett Manale: Tro inte på hype.
Eric Kavanagh: Det kan finnas några små små saker som görs dynamiskt, men även det kanske du vill kolla in det och se till att det inte gör något du inte vill att det ska göra. Så under en längre tid kommer vi att behöva verktyg som detta för att förstå vad som händer på databasnivå och som Robin sa, är insjöar fascinerande koncept, men det finns förmodligen ungefär lika stor chans att de tar över som det finns av det finns ett Loch Ness-monster när som helst snart. Så jag skulle bara säga igen, den verkliga världen har mycket databasteknologi, vi behöver människor, DBA, för att titta på det här och syntetisera det. Du kan berätta, du måste veta vad du gör för att göra det här. Men du behöver verktygen för att ge dig information för att veta vad du gör. Så i slutändan är DBA: s kommer att gå bra.
Och stort tack till Bullett Manale och våra vänner på IDERA. Och naturligtvis Rick Sherman och Robin Bloor. Vi arkiverar alla dessa webbsändningar, så hopp online insideanalysis.com eller till vår partnerwebbplats www.techopedia.com för mer information om allt detta.
Och med det säger vi dig farväl, folkens. Tack igen, vi pratar med dig nästa gång. Ta hand om dig. Hejdå.
