Hämtmat: 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 är 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 pratar 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, de är inför verkliga kunder med transaktionssystem, oavsett vad som är fallet, vill du förstå hur dina system fungerar och vad som händer, och det är vad som pratar om idag. Det är ganska roligt eftersom prognoser inte är något jag gillar att göra, för att jag är vidskeplig, som 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 överlämnar jag det till Robin och påminner bara folk: Ställ frågor, var inte blyg, vi älskar bra frågor, lägg dem ut till våra presentatörer och andra idag. Och med det, Robin, ta bort det.
Robin Bloor: OK, ja, när jag är i polspositionen som de säger, trodde jag att jag berättar en SQL-historia idag, för det är bakgrunden för vad diskussionen kommer att fortsätta och det kommer oundvikligen inte att kollidera med eftersom Rick inte fokuserar på detta , och kommer inte att kollidera med vad Rick har att säga. Så SQL-berättelsen, det finns några intressanta saker om 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 fungerade ganska bra, faktiskt, men det finns ett antal saker som är ganska värda att säga om det, konsekvenserna 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 det som ä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, det är bara 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 som de kommer att få, för de flesta av deras fokus handlar faktiskt om att manipulera data och inte på att få, lägga in 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 skriva SQL-frågor sådär. Dess någon har skapat, om du vill, en liten motor att oavsett parametrarna, det kommer att slänga ut lite SQL, och igen, att SQL inte nödvändigtvis kommer att vara effektiv SQL.
Då tänkte jag att Id nämna impedansmatchningen, 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å blir det en dialog sak, ja, SQL var inte byggd för dialoger, den byggdes för att fråga vad du vill ha på en gång. Och det är 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 den här typen av sprider sig till allting - ja, det finns CPU, theres minne, theres disk, dess nätverkskostnader och det finns låsningsproblemet 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. Tja Robin, när vi började i början av presentationen är min grafik fortfarande ganska tråkig, men gå med det. Så jag håller med om allt som Robin talade om på SQL-sidan. Men det jag nu vill koncentrera mig lite på är efterfrågan på data, som väl går 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 som 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å, fortfarande pratade, som Robin talade, om SQL. Och faktiskt, även om vi tittade på Hadoop-plattformen, är Hive och Spark SQL - som min son, som 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 ett brett belopp och en expanderande mängd data som finns i datalager och andra affärsintelligensbaserade system. Orsak allt, oavsett var och hur det fångas, lagras eller transakteras, så småningom analyseras och så finns det en enorm efterfrågan och ökning av användningen av databaser, särskilt relationella databaser ute på marknaden.
Nu har vi fått efterfrågan, vi har enorma mängder data som kommer. Och jag pratar inte riktigt bara om big data, jag pratar 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 personer som har DBA-jobbtitlar, men pratar väl om det på en sekund - kontra 40-plus-procenten å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 nu för att DBA-jobbet blir allt svårare. Först och främst har vi DBA som själva hanterar många olika databaser, 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 dess relation 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 pratade 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 i själva databasstrukturen. . Så vi har mycket dålig design.
Nu pratar jag inte om leverantörerna av kommersiella företagstillämpningar; de har vanligtvis ER-modeller eller utökade ER-modeller. Vad jag pratar om är att det finns mycket fler affärsprocesser och applikationer som byggs av applikationsutvecklare i varje företag - det är de som inte nödvändigtvis är utformade för effektivitet eller effektivitet i distributionen. Och DBA: erna är överarbetade och de har 24/7 ansvar ibland, de får hela tiden fler och 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 att tänka, ”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 små IT-team 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ärsinformation under en 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. Var ansvarig 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 utformar inte det för effektivitet.
Och det finns en stor 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 - personer som är skickliga och experter på dessa inställningar och utformning och hantering och implementeringssituationer. 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 också 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 många gånger de inte bara förstår vad de ens behöver se på i designen eller när de hanterar eller driver 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 tittar 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öretagsapplikationer som krävs i 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 använder det, vad datavolymerna är , när det kommer att hända. Vad 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, naturligtvis, du försöker 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 väntetiderna och genomströmningen - oavsett du måste 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. Nu när du tittar på att övervaka prestandan vill du titta på själva databasverksamheten. du vill titta på både datastrukturerna, så att indexen, partitioneringen och andra fysiska aspekter av databasen, till och med databasens struktur - oavsett om det är ER-modell eller dimensionell modell, dock strukturerad - alla dessa saker har inverkan på prestanda , särskilt i de olika nackdelarna med datafångstanalys och de transformationer som händer.
Och som Robin nämnde på SQL-sidan, att titta på SQL som drivs av dessa olika applikationer över dessa databaser och ställa in det är avgörande. 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örs på - också tittar på effekterna som dessa applikationer och dessa databaser har inom det con, 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 som fungerar bra, vad som inte fungerar 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 läge, om vi ökar kapaciteten, om vi får fler användare, om vi gör mer genomströmning, vad som än gjorde, att kunna projicera vad, hur och var som kommer att påverka databasen, applikationerna, tillåter oss att planera för och räkna ut 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 det passar, jag vet inte för er som är "A-Team" -fans tillbaka på 80-talet, John Hannibal Smith hade ett ord som säger alltid: "Jag älskar det när en plan samlas, ”och jag tror att när du pratar om speciellt SQL-servern, som var där fokuserade, vilket är produkten som skulle prata om idag, SQL Diagnostic Manager, det är definitivt en av de saker som 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 är du inte ute 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, en av de saker som det gör mycket bra kommer att hjälpa dig när det gäller prognoser och förståelse specifikt för arbetsbelastningen och skulle 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 vara en hel del 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 är inte bara att säga "Hej, gör det här."
Eftersom jag agerar 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 jag pratade 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 är du alltid på något sätt ansvarig för din lagring, din planering av lagring och förståelse för att förutse, jag skulle säga, hur mycket utrymme du kommer att behöva, vare sig det är för dina säkerhetskopior, eller om det är för själva databaserna. 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 efter behov baserat på saker som förändras i miljön. sig. Så saker som antal användare, saker som popularitet för applikationer, säsongsbetonade databaser, 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 betyder att kunna titta specifikt på en viss metrisk och förstå vad värdet av det metriken 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 prognoser, och jag har lagt definitionen här av kapacitetsplanering. Och det är en ganska bred och faktiskt ganska vag definition, som bara är processen för 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: Dess 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 sätta lite på 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 pratade om, var vettigt i den meningen att du förlitar dig på historiska 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 radioannonser för någon som säljer värdepapper eller något sådant, är dess alltid "tidigare resultat 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, kommer du att stöta på, är mycket värdefullt och det kommer att ge dig mycket längre än att spela gissespelet.
Så dessa typer av frågor uppenbarligen kommer att komma upp, så hur vi hanterar en hel del 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 såväl som enhet eller volym. För att inte bara kunna säga: "Hej, var full av utrymme", utan sex månader från och med nu, två år från nu, fem år från och med nu, om jag budgeterar för det, hur mycket drivrutin ska jag behöva budgetera för? Det är frågor som 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 mycket ibland 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 du ska gör, baserat på det är ytterligare ett hopp. 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 väl 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.
Gå vidare till nästa här, som väl ser, det är bara generellt sett förståelse 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å, 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 en med varningsperspektiv, 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å vad 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 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 mycket 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 ens ö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 för att kunna använda dessa mätvärden i samma form och på samma sätt som du skulle använda dem om du använder en out-of-the-box metrisk, till exempel. Så att kunna köra rapporter, kunna varna, baslinjen - allt det som pratade om - är också en viktig del av att kunna göra denna prognos och göra det så att du får svar som du letar efter för att kunna göra dessa beslut, framåt.
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 data, uppenbarligen, är vi 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 gillar att göra, och det här är bara ett snabbt exempel på arkitekturen, det stora takeaway här är det inte några agenter eller tjänster som faktiskt sitter på de instanser du hanterar. Men vad jag gillar att göra är att bara ta dig in till applikationen 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 något som du behöver göra, eller här är något som är en tidpunkt i framtiden och skulle 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 under en tid, och jag kommer bara att ge dig ett par exempel på det. Så jag ska ta min revisionsdatabas, som är ganska I / O-intensiv - det har mycket data som kommer till den. Weve har, låt oss se, väl göra 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 de senaste åren värt data" - och jag kommer att fibra här lite, jag har verkligen inte några år värt data, jag har ungefär två månader värt data - men eftersom jag väljer en samplingsfrekvens på månader här, kommer jag att kunna förutse eller förutspå i det här fallet de kommande 36 enheterna eftersom vår samplingshastighet är inställd på månader - det är en enhet, är en månad - och sedan skulle jag kunna, för att sedan köra 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 som de historiskt konsumerar.
Vi kan se datapunkterna här representera historiska data, och sedan raderna kommer 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 som 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, det är en sak, gör det faktiskt genom att ge dig ett specifikt datum och kunna säga "Hej på det här datumet, det är här vi kan förutse att tillväxten av dina uppgifter kommer att vara." Utöver detta kan vi dock ge 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 bra, 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å, vad vi har här, är ett bättre sätt för dig att kunna förstå, om jag kommer att vidta åtgärder för att hjälpa till med prestanda, om jag kommer att vidta åtgärder för att till och med hjälpa till med min hälsa miljö, att kunna ha ett rankat sätt att tillhandahålla dessa rekommendationer, samt användbara tips i information för att lära sig mer om dessa rekommendationer och faktiskt ha även externa länkar till en del av den informationen, som kommer att visa mig och ta mig till skälen till dessa rekommendationer görs.
Och i många fall att kunna tillhandahålla ett skript som automatiserar, som sagt, saneringen av dessa problem. Nu, en del av vad som gjorde här med denna analys - 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 listas här, och del av det har vi indexoptimering och frågaoptimering. Så vi utvärderade inte bara själva statistiken och sådant, utan också saker som arbetsbelastningen och indexen. I det här fallet, gör 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 är det en slags tipppunkt, där jag säger: ”Tja, bordet kommer till storleken eller de typer av frågor som körs inom arbetsbelastningen är vettigt nu att lägga till ett index. Men det skulle inte ha 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 vilken metrisk vi vill - och låt mig hitta en anständig här - Jag går till 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 outliers är, för att se generellt sett där 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 förmågan 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 kan ha 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 vi 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 dessa baslinjer som vi genererar med hjälp av historiska data för att tillhandahålla den analysen, men ännu viktigare, jag kan ändra dessa tröskelvärden 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 kommer upp, skulle dessa trösklar automatiskt växla specifikt till de belastningar som jag stöter på under det fönstret av tiden, kontra kanske mitt på dagen när mina belastningar inte är så 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 också förstå vad som är normalt och att 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, det 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 att svara på frågor om vad som händer.
Så som ett exempel, om jag hade 150 instanser jag hanterar - i mitt fall jag inte, 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, 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å om dess diskanvändning, minnesanvändning, om dess väntar, vare sig dess responstid, jag kan korrelera - eller jag borde säga rang - dessa instanser mot varandra. Det är uppenbart att instansen är högst upp 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 basstatistikrapport. 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åter se baslinjen för detta som har brutits ut 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 kunna fatta några beslut som använder den informationen, uppenbarligen, så detta ä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 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 verkligen viktigt också att dessa rapporter och dessutom alla de saker som vi redan har visat dig i verktyget, som jag nämnde tidigare, med flexibilitet att införliva nya mätvärden, att hanteras, till och med kunna skapa räknare, eller SQL-frågor som ingår i dina pollingintervaller, för att kunna hjälpa mig att svara på dessa frågor, att du kanske inte har förutsetts att övervaka att du kan lägga till det. Och du skulle kunna göra alla samma saker som jag just visade dig: baslinje, köra rapporter och skapa rapporter från den metriken och kunna svara och göra mycket av dessa olika typer av saker som jag visar dig här.
Nu, utöver det - och en av de saker som vi uppenbarligen stöter på en hel del på sistone är - först var det, 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 de olika sakerna. 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 när det gäller de andra typer av miljöer som vi ser människor på väg till. Och det finns fortfarande en hel del frågor kring dessa grejer, 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, när det gäller detta ämne. Jag vet att ämnet för affärsintelligens kom upp och att vi också har ett verktyg för företagsinformation som vi inte pratade om idag, men det kommer också att ge dig insikt när det gäller att besvara dessa typer av frågor när det gäller dina 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 kastar det till Rick, om han fortfarande är ute. Rick, några frågor från dig?
Rick Sherman: Ja, så först upp, 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: Vi måste fortfarande betala för det, eller hur? Du har fortfarande att betala för vad det är som folk sätter på molnet, så om det är dåligt kör, eller om det orsakar en hel del CPU-cykler, dess mer pengar du har att betala, så det är inte, du måste fortfarande mäta det här, absolut.
Rick Sherman: Ja, jag har sett många 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 det. Vi har många olika sätt att identifiera frågeställningar, oavsett om det är relaterat till, specifikt att vänta som vi ser i den här vyn här, eller om det är relaterat till resursförbrukningen av frågor övergripande, det finns ett helt antal sätt vi kan analysera frågan prestanda. Det är oavsett om dess varaktighet, CPU, I / O, och än en gång, vi kan 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 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 den beroende, den ä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 så kan jag också. Jag kan samla in information relaterad till frågor som överträffar en tidsperiod, exekvering. Som ett exempel på detta, om jag skulle gå in på konfigurationsfrågorna och jag skulle säga: "Låter ändra detta värde till noll", är verkligheten att det bara gör att verktyget bara samlar in alla frågor som körs och det är verkligen inte anda av varför det är där, men i allmänhet om jag ville tillhandahålla ett fullständigt urval av data för alla frågor skulle jag kunna göra det.
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, skulle inte 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 termer av hur vi skulle gå åt att samla in dessa data, men som sagt, som jag sa, vi har funnits för jag antar sedan 2004 med den här produkten. Det har funnits 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 är eventuellt uppdelad 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 talar du om i allmänhet 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 ett DBA-perspektiv, många gånger händer dessa problem när de är framför konsolen, så att kunna meddelas 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 en del nackdelar till varför det händer. Och så det är, tror jag, den största delen: att vara aktiv med det, inte vara reaktiv.
De flesta av DBA som jag pratar med - och jag vet inte, det är en bra andel av dem - tyvärr finns fortfarande i den reaktiva typen av miljö; de väntar på att en konsument ska kontakta dem för att berätta för dem att det är 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 det är kanske bara DBA som berättar 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, de är de som kommer att ta skylden, orsaka att de tar den applikationen till sina system eller servrar och sedan när prestandan är dålig 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 av webbplatserna som jag känner till, men det har gått ett tag sedan jag har varit ute och tittat på flera multidatabaser, men mest vad jag brukade hitta var att det skulle finnas 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ältalande, är som det finns vissa databaser som DBA bryr sig om och sedan finns det några som de inte bryr sig om lika mycket. Och det sätt som den här produkten, hur dess licensieras är per instansbasis. Så det finns, antar jag att 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 har som är mer , Antar jag att jag kommer till 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 som jag vill ställa mig själv, men för det andra, hur viktig ä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 de är de elementära typerna av saker jag bryr mig om som en DBA: Fyller enheten? Svarar servern på problem? De viktigaste sakerna, eller hur?
Medan Diagnostic Manager, verktyget jag bara visade dig, det kommer att komma ner till fråganivån, det kommer att komma ner i rekommendationen av index, titta på exekveringsplanen och allt det där bra, medan detta huvudsakligen är fokuserat på vem som äger vad, vad är det som jag äger och vem som 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 är 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 ny 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. Är det 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 såg att vissa av uppgifterna flyttades in i de andra segmenten där det är mer meningsfullt när det finns andra tekniker som finns tillgängliga. Som nyligen, några av de större data grejer. Men dessa databaser, skulle jag säga, är svåra att generalisera i många fall för att 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, för att i allmänhet folk som jag pratar med alla har de traditionella databaserna och använder detta i en SQL Server-miljö.
Som sagt, Id säger när det gäller SQL själv, jag tror definitivt fortfarande att det har fått 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 prisvärt och verkar vara uppenbart eftersom SQL-versioner blir mer avancerade - och du ser detta med de senaste sakerna som pågår på med SQL, när det 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 jag såg det också. Där du ser en förändring 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öerna 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 en 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 ett 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 berättade 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, för många av dessa, kommer manuset att byggas för det. Det är inte 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 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 detta kommer att ge mig ett bra segment till de slutliga kommentarerna här. Robin och jag och Rick har också hört under många år nu, det är prat om databaser med självinställning. Det är en självstämningsdatabas! Allt jag kan säga er att: tro inte på dem.
Bullett Manale: Tror 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, datasjöar är fascinerande koncept, men det är förmodligen ungefär lika stor chans att de tar över som det finns. ett Loch Ness-monster när som helst snart. Så jag vill 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 få dessa saker att fungera. 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, välkomna farväl, folkens. Tack igen, prata med dig nästa gång. Ta hand om dig. Hejdå.