Prestationsspel: säg adjö till latens

Av Techopedia Staff, 9 maj 2016

Takeaway: Värd Eric Kavanagh intervjuer Mark Madsen, Dez Blanchfield och Bullett Manale om latens och prestanda.

Du är för närvarande inte inloggad. Logga in eller registrera dig för att se videon.

Techopedia Content Partner

Techopedia Staff är anslutet till Bloor Group och kan kontaktas med alternativen till höger. För information om hur vi arbetar med branschpartner klicka här.

• Profil
• Hemsida

Eric Kavanagh: Mina damer och herrar, hej och välkomna återigen till Hot Technologies! Ja verkligen! Jag heter Eric Kavanagh, detta är vår Hot Tech-show, ett partnerskap med våra goda vänner från Techopedia. Hoppa online till Techopedia.com för allt det senaste inom det breda området för företagsteknik; de täcker naturligtvis också konsumentartiklar också. Vi fokuserar på företaget här på vårt program, så det är vad vi gör idag.

Det finns en plats om ditt verkligen och tillräckligt med mig, slå mig upp på Twitter @eric_kavanagh, jag älskar Twitter, jag älskar att kolla in det, det är ett utmärkt sätt att hålla kontakten med människor och ha goda samtal, och en-på -samtal.

Så vad pratar vi om? Det här året är varmt, detta är ett helt universum av möjligheter som vi tittar på i dag i världen av informationshantering, och det vi pratar om idag kommer att bli frågor, det kommer att påskynda frågor.

Jag tror att jag glömde att nämna titeln "Performance Play: Say Goodbye to Latency." Nåväl vem vill ha latens? Ingen vill ha latens, latens är när du sitter där, klickar på knappen och väntar på att något ska hända, och ingen vill ha det. Barnen gillar det inte, de tycker inte att det är coolt, de vuxna gillar det inte heller. Vi har alla varit bortskämda av hastigheten på webben, och vi vill ha saker snabbt, vi vill ha saker nu, och vi ska prata allt om det idag på vår show.

Analytiker Mark Madsen är med oss ​​idag från Third Nature, en av våra stamgäster. Vår nya datavetare, Dez Blanchfield, anropar från Sydney, Australien. Och sedan Bullett Manale, ja, det är hans namn, det är faktiskt tänkt att vara två T: er. Bullett Manale fortsätter som vår gäst från Idera, ett mycket, mycket intressant företag, som gör mycket saker. Jag vet redan om dem, varav en köpte ett företag som heter Precise för en stund tillbaka. Jag visste att deras VD heter Zohar Gilad, hur är det för ett namn? Han var en smal kille.

Men folkens, ni spelar en viktig roll i denna webcast i frågorna som ni ställer, så var snäll inte var blyg, skicka era frågor när som helst - ni kan göra det med hjälp av Q & A-komponenten i webcast-konsolen, det är där nere i nedre högra hörnet. Du kan också chatta med mig och jag ska chatta det till högtalarna. Vi har redan någon som ringer från Italien så, “Ciao, ciao. Kom stai? ”Okej, med det kommer jag att trycka på Marks första rad, jag ska överlämna däcket till Mark. Markera, du har nu WebEx. Ta bort det, golvet är ditt.

Mark Madsen: Tack, Eric. Men jag kommer inte att börja i mitten, men jag börjar i början. Så bara några kommentarer för att sätta upp diskussionen med Dez och Idera, ett slags statligt tillstånd med utveckling, och databaser och operationer. Och du vet, om du tittar på det här så har vi den här typen av två världsproblem som fortfarande finns på databas- och applikationsmarknaden, eftersom utvecklare ser DBA: er som de människor som krångel dem. Du måste bygga datamodeller, du kan inte ha åtkomst till det, du kan inte skapa det, du kan inte sätta ett index i varje kolumn i varje tabell i databasen för att göra det snabbare. Och naturligtvis, varför behöver vi modellerna? Det är bara datastrukturer, om vi ändrar dem, kan du inte bara skriva ut dem i serieform?

Problemet är att utvecklare känner till kod och applikationer, men två saker som de ofta inte vet är samtidighet, samtidig programmering och databaser och operativsystemen under dem. Efter att ha varit en kärnutvecklare och operativsystem och databaser kan jag säga att samtidighet och parallellitet är riktigt svårt, och så mycket av de saker som du lär dig att få bra resultat från din kod, börjar verkligen falla isär när du är arbetar med en databas. Och prestanda ser bra ut, testmiljön ser bra ut och Q & A-miljön, och sedan träffar det det verkliga systemet, och så är det plötsligt inte så bra. Eftersom den är mångfacetterad, hur koden fungerar med databasen, hur den fungerar med miljön och verkligen enkla små metoder kan ha drastiska effekter beroende på vilken skala du kör.

Och när du börjar prata om externa applikationer kan naturligtvis externt vända applikationer, webbapplikationer, vara riktigt svårt eftersom saker är fantastiska tills de plötsligt plattlinjer, och det är de inte. Du kommer att träffa dessa intressanta platåer som kräver mycket nyans för att förstå.

Tidigas övergången är DBA-uppfattningen. DBA-uppfattningen är att det finns operationer, de tillbringar huvuddelen av sin tid, 80 till 90 procent, i ops, och kanske 10 till 20 procent som handlar om utvecklingsmaterial som pågår. Ur detta perspektiv betalar du antingen nu eller betalar senare, och om du spenderar all din tid på förhand, kommer du att ha en mycket bättre chans senare, i motsats till utveckling som tenderar att utforska en funktion utrymme och försöka ta reda på hur man bäst gör saker. Och så har vi problem, och nu har vi metoder som är oförenliga - kontinuerlig distribution, rulla upp dina appar när de är redo, gör kodknappar med jämna mellanrum, arbetar i en butik som utövar dev ops. Den här typen av saker påskyndar utvecklingen, men all praxis runt databasen och vad DBA: er gör och vad systemchefer har utbildats för att göra, IT-uppsättningar har inte hållit tritt.

Om du tänker på det fungerar de flesta DBA: er under en förändringskontrollmiljö jämfört med en kontinuerlig implementeringsmiljö. Det handlar om stabilitet och kontroll, mot förändringshastighet och reversibilitet. Kontinuerlig implementering, om du inte kan backa ut ur förändring, är du i problem, så allt måste byggas för att vara lätt reversibelt och kodbytbart, vilket inte är så som relationella databaser, utvecklingsmetoder och hanteringsmetoder har fungerat .

Du stöter också på dessa problem med att behöva vara mer proaktiva om du kan, som en DBA, för när du hör till ett problem, fyller hundra tusen människor klagomålsformulär på din webbplats. Det gör att du behöver några nya saker som du inte får ut ur din gamla miljö. Du vet, saker som bättre övervakning och varning. Samtidigt har databaser multiplicerats, vi har fler applikationer än någonsin för att stödja fler saker än någonsin, de är inne, de är ute, de är överallt. Och mer oberoende uppsättningar av data för analyser, människor startar databaser överallt, för det är naturligtvis enkelt nu, du kan ställa in en virtuell maskin. Om du har en molnleverantör eller ett internt moln kan du omedelbart dyka upp saker, och detta ändrar hela inköpsvägen.

Den gamla upphandlingsvägen var: "Jag har tid att få en server, skjuta den i ett rack, tilldela utrymme, få lagring, få databasen installerad och göra saker, " kontra någon som sveper ett kreditkort och går på fem minuter. Om du gör det fungerar den moderna utvecklingsmiljön i en takt som är väldigt annorlunda, och så det är lätt att skapa databaser, och det skapar bara detta problem med en spridning, som ingenting vi har sett tidigare. Och detta har pågått i tio år nu, det är ingen nyhet för någon, men det betyder också att driftsmiljöerna har vuxit i komplexitet.

Hela klientservermiljön har verkligen förändrats, eftersom det inte längre är en klientservervärld. Då hade du en server, du hade en databas, om något var fel visste du vilken server du skulle gå till, du visste hur du hanterar resurserna på den eftersom bästa praxis var en databas, en server. Virtualisering började bryta sönder, molnet bryter det ännu mer, för det du tror är en databaseserver är bara programvara. Så miljön är inte riktig. Det är det som innehåller miljön som är verkligheten, och det kan vara ett knivblad eller en stor server som är huggen upp i bitar, du vet inte riktigt.

Allt kring databasadministration och prestationshantering, och vilka databaser som har byggts kring snäv kontroll med en server, eller en handfull servrar och ett par databaser, kan du inte kontrollera allt. Du sitter där på en maskin, men bandbredd kan inte delas upp enkelt av de virtuella cheferna, och så kan allt gå bra med minne och CPU, men du är flaskhalsad på en resurs som inte kan hanteras, och sedan när du försöker fixa den, den gamla modellen hade varit på hårt arbete, fått en större server och göra något liknande, nu kan det vara riktigt enkelt, bara lägga till virtuell kurs, bara lägga till minne till VM och det är löst. Men vad händer om din VM finns på en överfull server och måste migrera? Eller vad händer om du är på storleken på ett AWS-system och maxstorleken har nåtts, vart ska du gå?

Så du har alla dessa problem där miljön är en del av databasen nu, du paketerar en miljö med en databas, alla specialresurser, allt i applikationen, det är en del av konfigurationen, konfigurationen skjuts ut där. Detta kommer från databasmiljön, det är mycket svårare att hantera och kontrollera.

Om du tittar på vad databascentra har gjort så har de sittat på sina händer, eller hur? Vi har gått bort från denna idé om att behandla databaser och servrar som husdjur. Servrar har namn, du behandlar dem som om de är individuellt unika saker, du behandlar dem som nötkreatur, det hanterar en besättning. Och problemet med att hantera besättningar är att om du inte kontrollerar dem så småningom kan de stämma, och en stämpel är inte bra. Vi behöver bättre övervakningsverktyg, vi behöver bättre sätt att hantera det här och veta vad som har påverkats. I den gamla modellen var det lättare eftersom dina operatörer och alla dina styrsystem berättade för dig, men när ditt servernamn är en UPC-kod är det lite svårt att ta reda på saker.

Du har inte råd med falska varningar, du har inte råd med saker som säger "Det finns ett problem med den här maskinen och den maskinen är värd 30 databaser." Du har inte råd att ha saker som inte ger dig någon historia. Övervakningskonsoler är bra när de tänds, men om det röda ljuset blir grönt igen och du inte vet varför, och du har ingen historia att gå tillbaka till för att titta på vad som ledde till det, och vad sammanhanget var, du är i problem. Vi behöver system som kommer att övervaka för oss, vi behöver bättre övervakning, hantera de kuriva intermittenta problem som upprätthåller datahistoriken.

Bättre saker och enkla mättröskelvärden som får oss nyckeltal, men leda oss inte direkt in i vad som är normalt, vad som är onormalt och hur ofta dessa problem uppstår. Det vi verkligen pratar om är en kombination av övervakningsmiljö och hantering av prestanda, och leverantörerna har sittat på sina händer. De har inte gett oss bättre verktyg. Vi har system med mer CPU och minne än vad vi vet vad vi ska göra med allt, och ändå förlitar vi oss fortfarande på manuella interventionsmodeller, vi har inte satt maskinen i arbete, för att vägleda oss, för att få oss till problemet., vi har inte kommit till den här nya stilen, som är "Det finns ett problem här, du kan göra detta för att fixa det", eller "Det finns ett prestandaproblem, det är faktiskt med detta specifika SQL-uttalande, här är tre saker du kan använd för att fixa det SQL-uttalandet. ”Tillämpa heuristik, tillämpa maskininlärningsmodeller som kan titta på användningsmönstren för ditt system för att upptäcka problem och undvika falska varningar. Använd maskinen för att göra det som maskinen gör bäst, för att förstärka DBA eller för att förstärka den person som måste hantera prestandaproblem.

Det är det nya sättet, i motsats till den gamla stilen. Det finns ett problem med den här databasen, saker är långsamma, och så vi har nya tekniker, nya sätt att göra det, och vi borde tillämpa dessa, och det är där marknaden är på väg. Du ser att det börjar växa upp, inte med de stora leverantörerna, utan med tredjepartsföretag, och detta speglar något som hände för 20 år sedan när databasleverantörerna inte gav en enda sak för att hjälpa till att hantera systemen. Så det är typ av marknadens inriktning, och med det skulle jag vilja lämna tillbaka den till Eric.

Eric Kavanagh: Okej, jag ska överlämna det till Dez. Och Dez, ta bort det, golvet är ditt.

Dez Blanchfield: Tack, Mark. Du har gjort ett fantastiskt jobb med att täcka den tekniska delen av det. Jag kommer att komma till det från en något annorlunda vinkel för att lyfta fram vad som hände i resten av världen, så långt som det påverkar företag och databaserna runt dem. Låt mig bara hoppa till min första bild.

På baksidan av vad du just har täckt från den tekniska sidan av saker och utvecklarens sida av saker, ser jag företag måste möta utmaningen med data och databaser i synnerhet, och uppenbarligen har vi haft denna betydande förändring mot detta koncept med big data, men databaser är fortfarande hjärtat och själen där organisationer behåller sin affärsinformation, och det är från ytterdörren hela vägen till back office. Varje del av organisationen berörs av en databas av något slag och drivs av en databas, och mycket sällan går jag in i antingen projektdiskussioner eller någon form av innovativ strategisk konversation i en organisation där ämnet för databasen eller databassystemet kommer inte upp, och det finns alltid frågor kring de typer av saker vi just har hört talas om, vad gäller prestanda och säkerhet och hur kommer utvecklingen närmar sig denna utmaning, och var passar databaserna, och våra medvetna om miljöer och applikationer miljöer pratar med, hur är det med enheter och mobilitet?

Det är fortfarande ett väldigt, mycket hett ämne, och det har varit ett under en lång, lång tid i det stora planen för saker så långt modern teknik går. Därför tror jag att det är ett faktum att nästan allt vi gör i våra dagliga liv, våra vardagsliv, det vill säga, nu stöds av någon form av databas. När vi tänker på alla saker runt oss, oavsett om det är en faktura som kommer i posten varje dag för någon tjänst vi köper, skrivs det oundvikligen av ett system som pratar med en databas, och vi är där inne. Våra telefoner har databaser med dem med kontakter och samtalsloggar och andra saker.

Vart vi än går, finns det någon form av databas bakom samtalen och de system vi använder, och oftare är de ganska transparenta för oss, men faktum är att de är där. Så jag tänkte att jag bara snabbt skulle täcka varför detta har blivit lite problem på mycket kort tid. I början kom databasbegreppet från denna härliga herre, Edgar Codd. Medan han arbetade hos IBM förändrade han världen så långt som datahantering går genom att skapa ett koncept som vi nu refererar till som en relationsdatabas.

I början var databasen en databas och livet var bra, det var ganska enkelt både i kolumner och referenser, och så vidare, och tabeller, och att utveckla programvara var ganska enkelt, och prestanda var egentligen inte så stort problem - det var en ny spännande teknik. Vi fick tillgång till databaserna genom någon form av terminal, och du kan bara skapa så mycket förödelse i slutet av en 3270-terminal på en stordator, och alltid andra typer av terminaler, de andra systemen kom med. Och i de flesta fall liknade de gamla stilterminalerna mycket vad webbmiljöerna är nu, och det är att du skulle fylla i ett formulär på skärmen på själva terminalen och trycka på Enter och stänga av det skulle gå, det skulle skjut av som ett paket, som en begäran, och back-end-systemet skulle hantera det. Det är i grund och botten vad som händer i en webbläsare i dag, när du skriver in en länk i en webbläsare och den formen går den vanligtvis inte i realtid tillbaka till systemet, även om det med AJAX i dag är det inte helt fall.

Men då hände något, framtiden kom, och nyligen internet, och nästan igår, i en sekund 2.0, och precis runt hörnet har vi Internet of Things. Och i processen för framtiden som händer har databasvärlden just exploderat, och interaktionen med databaser blev bara en sak som vi alla gjorde som standard, det var inte så att du skulle gå någonstans för att göra något, som att köpa en biljett till ett flygplan och vill resa till andra sidan planeten, någon var tvungen att skriva in terminalen alla dina detaljer och gå in i en databas och skriva ut en biljett.

Nästan allt vi gör nu, oavsett om det är en hytt på Google med en applikation, oavsett om det hoppar på internetbank, allt vi gör på en daglig basis, med ett slags system, det drivs av en databas. Och när internet kom med, var det lite lättare att ta med oss, våra vardagsliv genom en webbläsare, och sedan kom webb 2.0 och saker blev mobila och omfattningen av saker bara exploderade. Faktum är att min favoritrad i detta ämne är: "Internet anslöt allt, webb 2.0 gjorde det mobilt och socialt, och saker blev väldigt, väldigt stora och nu har vi internet och saker och, och IoT … Yikes !!" Vi har inte ens börjat föreställa oss vilken inverkan Internet of Things har när det gäller världen på databasesystem.

Så i moderna termer, vad vi brukade tänka på som en terminal har faktiskt blivit dessa saker, det är mobiltelefoner, det är olika typer av surfplattor, antingen personliga konsument- eller företagsklass storskärms-surfplattor, det är bärbara datorer och det är det traditionella skrivbordet i någon form. I den ena bilden kan du se nästan alla former av gränssnitt som vi nu använder för att prata med databasesystem och appar som drivs av dessa, från de små prylarna i våra händer som går runt och vi verkar vara limmade till, alla vägen till de något större versionerna, iPads och andra surfplattor och Microsoft Surfaces, till vardagliga bärbara datorer, vilket alltid är fallet i professionella miljöer och så vidare. Människor tenderar att få en bärbar dator och inte ett fast skrivbord, men de är den moderna terminalen enligt min åsikt och en del av anledningen till att databaser upplever alla typer av utmaningar i ledningsprestandardelen i våra liv, och inte bara utveckling.

Så jag antar att det är en av de största utmaningarna som företagen fortfarande står inför dag för dag. Alla trodde att databaser var våra enda problem, det är de inte. Så vad handlar det om? Tja när vi går från ena änden till den andra med alla saker relaterade till databaser, från kommersiell mening, och Mark's täckte de tekniska komponenterna mycket, mycket bra, men i kommersiell mening, som organisation, tänker vi på databaser. Vi har att göra med saker hela vägen från den grundläggande design- och utvecklingsfronten. När ett företag startar kommer de att tänka på att utveckla applikationer, utveckla en kapacitet eller till och med implementera en befintlig applikation i någon form. Någon form av design och utveckling måste äga rum och en hel del tankar måste göras över hur dessa databasesystem kommer att implementeras, stöds och hanteras, och spårningar spåras och så vidare.

Integrationen av databasmiljön och applikationerna och typerna av API, de typer av åtkomst som tillhandahålls nu blir mer och mer utmanande, mer komplexa. Daglig administration, support och säkerhetskopiering, återigen, det här är saker som vi trodde löstes, men så plötsligt blev skalan mycket större, och saker rörde sig snabbare, och volymen är så mycket större; Miljöernas storlek, databassystemen var tvungna att stödja hastigheten med vilken transaktioner rör sig.

Tänk på en databas i en mycket, mycket högfrekvent handelsmiljö, det finns bara inget sätt människor kan hålla reda på med det, det är bara ett kluster av maskiner som kämpar mot ett annat kluster av maskiner för att göra högfrekvent handel, köpa och sälja, och volymen på som dessa transaktioner händer. Tänk på ett modernt scenario, som en tidig utgåva av en Netflix-film där du inte pratar om bara hundratals eller tusentals, eller till och med hundratusentals, potentiellt miljoner människor som vill se den filmen redan från den andra versionen. All den informationen fångas, spåras och loggas och analyseras i en databasplattform.

Och så finns det den alltid-på-världen som vi lever i nu, dygnet runt, inte bara följer solen utan det finns alltid någon uppe vid midnatt som vill göra något, och öppettiderna följer solen över hela världen. Så drifttid och tillgänglighet är som standard, är ett klimat nu, att ha en strömavbrott är egentligen inte en acceptabel sak. Och redundans, om det finns en prestationsproblem eller om vi behöver ett underhållsfönster för att göra en uppgradering eller en korrigering, eller en säkerhet, verkligen, måste vi kunna klippa från en databasmiljö till en annan och göra det sömlöst och automatiskt.

Säkerhet och standarder och efterlevnad, vi har fått några ganska stora saker hända i den sena världen, GFC i synnerhet, och så vi har en hel rad nya utmaningar att möta kring efterlevnad, säkerhet och matchande standarder, och vi behöver att kunna rapportera om dem i realtid och helst i en instrumentpanelform. Vi vill inte skicka ett team med apor till ett datacenter som försöker hitta saker, vi behöver systemet för att berätta för oss omedelbart, i realtid.

Och de två stora roliga som nästan ingen någonsin pratar om, vi skjuter dem i allmänhet under mattan och hoppas att de inte någonsin lyfter sitt fula huvud, utan katastrofåterhämtning och kontinuitet i kontoret - det är också saker som borde, för det mesta sker automatiskt om behovet skulle uppstå.

Vi kunde spendera dagar på att prata om de typer av saker som kan gå fel i databasmiljöer och att människor i allmänhet har svarat, men nu behöver vi system och verktyg för att göra det för oss. Ett exempel är ett dataöverträdelse, och så när vi tänker på databaser, och jag ställer denna fråga ganska öppet i olika former: vad händer med databaser när vi tar ögonen från bollen, och något kritiskt går fel? Särskilt om det inte finns ett system som tittar på prestanda och säkerhet och andra viktiga aspekter av att köra databaser.

Tja, vad som kan hända är detta, detta är en skärmdump av några av de senaste kränkningarna under de senaste två till tre åren. Ofta har dessa alla kommit från ett databassystem, och alltid har det varit något problem i säkerhet eller kontroll, eller åtkomst som har uppstått, och i det övre vänstra hörnet tittar vi på 152 miljoner Adobe-konton, där varje detalj av dessa kunder överträddes. Och om det var lämpliga verktyg som kanske hade funnits för att spåra och fånga händelsen och kontrollera säkerheten, kan vi ha undvikit några av dessa, de första par hundra rekord som stulits kanske har varnat oss, och vi skulle ha stoppade nästa hundra och femtio miljoner.

Då kommer vi till nyckelpunkten för hela denna resa, tagit oss igenom, det vill säga: varför behöver vi bättre system? Varför kan vi inte bara kasta fler kroppar på den här saken, att vi väl och verkligen har korsat tipppunkten enligt min åsikt, och jag tror säkert att det finns ett fall som har varit bevis på sent, att kasta fler DBA, administratörer och fler människor på den här saken löser inte problemet. Vi behöver en bättre uppsättning verktyg och en bättre uppsättning system.

Här är mina fem främsta skäl som jag tror stöder detta, och de rankas i viktigt ordningsföljd, baserat på vad jag ser i dessa privata företag och stater som är styrda miljöer, de utmaningar de står inför med databasmiljöer, och hantera dem.

Säkerhet och efterlevnad - nummer ett. Du vet, kontrollera vem som har tillgång, var har de tillgång, när de har tillgång, hur ofta de har tillgång, var de har åtkomst till det från. Potentiellt de enheter som de faktiskt har rört och vilka saker de har tittat på och efterlevnaden som går runt det. Att ha människor att driva rapporter 30 dagar senare för att berätta om saker är okej är inte lämpligt längre, det måste hända i realtid.

Prestanda och övervakning - det verkar som ingen brainer, men alltid är det inte. Oavsett om vi använder öppen källkodsverktyg eller vissa tredjeparts kommersiella verktyg, har vi alltid inte missat båten på många sätt med de typer av prestandaövervakning som krävs och detaljerna som och möjligheten att svara i tid .

Händelsedetektering och respons - det måste vara en omedelbar realtidssak, och alltid behöver vi ett system för att göra det för oss, eller åtminstone varna oss snabbt så att vi kan hantera det, så att de få frågor som uppstår behandlas med snabbt och kaskad inte ur kontroll.

Ledning och administration - igen, vi tror att dessa problem är lösade, de är det inte. Målet med frågor som databasgrupper står inför, särskilt DBA där ett system ska ta hand om saker för oss, vi har inte löst det problemet ännu, det är fortfarande en riktig sak.

Och helt från frontend med design och utveckling, när vi börjar bygga dessa verktyg, bygger vi databasmiljöerna, kan vi kasta lämpliga verktyg vid utveckling och testning och integration, plattformar. Detta är fortfarande inte en lätt sak för oss att göra, och hela denna resa, det driver oss på samma sätt till samma meddelande, att jag i min mening behöver bättre system och bättre verktyg för att hjälpa oss att leverera de resultat vi behöver från vår databasmiljö, så de företag som driver värde från våra kunder. Vi kan inte bara fortsätta kasta fler kroppar och fler DBA: er, skalan är för stor, hastigheten är för snabb och volymen är för hög. Med det, Eric kanske jag kommer tillbaka till dig.

Eric Kavanagh: Jag älskar det, vi har en massa mark täckta där folk, många potentiella leder, och vi går vidare och överlämnar de nycklar till Bullett på bara en sekund.

Bullett Manale: Okej.

Eric Kavanagh: Åh, låt oss ta bort det och Bullett, nu överlämnar jag det till dig, och golvet är ditt.

Bullett Manale: Okej, tack. Jag tror att många bra poäng har gjorts. Jag ville bara snabbt prata bara en sekund om Idera, vem vi är, och sedan hoppar vi in. Jag kommer att prata om verktyget som jag tycker mycket om det här vi pratar om, vi kan typ av uppsättning och typ av diskutera några av de områden där dessa överensstämmer med det här verktyget Diagnostic Manager-produkten.

Vad jag vill göra först är bara att ge dig lite bakgrund om vem Idera är; vi har funnits sedan cirka 2003, och så vi har börjat med bara SQL Server-verktyg, och det är vad vi kommer att fokusera på idag, är, skulle Diagnostic Manager-produkten vara. Men du kan se alla hinkar med saker som vi har här, och vi har nyligen, som nämnts tidigare, förvärvat Precise och genom förvärv har vi också Embarcadero, så vi har en ganska bra produktportfölj.

När det gäller prestandaövervakning, när det gäller SQL Server, är den produkt som jag vill prata om, som justerar dessa ämnen vi diskuterar, Diagnostic Manager. Nu är det en produkt som har funnits sedan ganska nära början av Ideras dagar, och jag har haft turen att vara en del av det sedan cirka 2005. Och jag har sett en hel del förändringar i termer av SQL Server, övergången från fysisk till virtuell, allt det som har hänt, och även DBA: s behov när miljöerna växer, och sådana saker.

Det jag började med var den typiska användaren av vår produkt är DBA, och så när vi pratar med folk för första gången, blivande kunder, är det mest DBA som vi pratar med. Vi pratar inte med IT-cheferna eller styrelseledamöterna, det kan vid någon tidpunkt komma till den nivån, men den första början är att DBA har ett problem, DBA försöker lösa problemet och många gånger vi Jag kommer att ladda ner och pröva produkten som en del av det. Du får antingen datahanteraren eller DBA eller den fungerande DBA, killen som är tur nog att vara den mest tekniska i rummet, i vissa fall. Nu, när du kommer till större företagsmiljöer, uppenbarligen, då kommer du att få de fullständiga DBA: erna som vanligtvis de som använder verktyget. Och jag gick vidare och lägger bara till en liten sudd här från Wikipedia. Det går typ av DBA: s ansvar som Wikipedia säger, det är vad de gör.

Om du går igenom listan här, en hel del av dessa saker, kommer jag inte att läsa av den, men du får mycket av de typiska saker du skulle tänka på, och sedan på en av dem har du övervakning och optimera databasens prestanda, och det är ganska stort. Och vad som är intressant är att när du pratar med DBA är de alltid de som skylls först, när det gäller problem, och det kanske inte riktigt är deras fel, men när det finns en prestationsproblem, vanligtvis med en applikation som är knuten till en DBA-databas, det är de som får skulden, så de letar alltid efter orsakerna till att det inte är deras fel. I många fall är det vad de kan använda det här verktyget, Diagnostic Manager, för att hjälpa dem.

Men i slutet av dagen, också, om databasen inte fungerar, så spelar inte mycket av det här andra saker, dina applikationer fungerar inte, då spelar det ingen roll för många av dessa saker. Först och främst vill vi kunna se till att användaren upplever hur vi känner till det, inte minskas, det är något som DBA alltid strävar efter. Och jag tror att om du tittar på orsakerna till att människor vanligtvis köper och använder SQL Diagnostic Manager-produkten, är ett av de första orsakerna, förmodligen inte det främsta, inte sist eller minst, men det är likadant över hela linjen, och beroende på vem du pratar med, dessa skäl, nästan en eller två av dem är alltid, finns det ett slags behov runt.

Men den första är bara att kunna ha den centraliserade bilden av instansen som en SQL som de hanterar. Och det roliga är att i många fall, om du frågar en DBA, "Hur många fall klarar du dig?" Antalet ändras så ofta att de inte är riktigt säkra i vissa fall. Så du behöver något mer än bara att kunna kasta upp allt på skärmen. Du vill ta tag i den informationen, du vill känna till den, och det är en av de saker som Diagnostic Manager definitivt kan hjälpa till med, är att kunna ge dig den typen av syn på miljön.

Och det är inte bara en syn på miljön, utan det är en uppfattning som DBA, databasadministratören, är bekväm med och det är en konsol som är DBA-centrerad, om du vill. Den är gjord för en databasadministratör. Det finns gott om övervakningsverktyg där ute, det finns gott om prestationsverktyg där ute, men som jag sa, i slutet av dagen vill DBA ha ett verktyg som är utformat för en DBA, eftersom det finns många saker specifika för vad de gör i deras dag till dag.

Och med det sagt, du har SCOM, du har HPF, du har alla dessa andra tekniker, men de vill ha något som är speciellt för det de gör. Jag tror att vi kan hjälpa till i det området med den här produkten, du kommer att se när vi kommer in på det på en sekund. Det andra som vi ser med DBA som definitivt är en av de saker vi också har berört tidigare är att de måste se vad som händer, och de måste kunna se över hela företaget och ha lite sinnesfrid när du vet vad som händer. Men samtidigt sitter de inte där och stirrar på konsoler.

Kommer du ihåg alla de kulpunkterna som du såg på den listan, som jag just tog upp? De måste göra de andra sakerna också, så det handlar inte bara om att vänta på att bränder ska släckas. I många fall kommer det att finnas möten, eller många underhållsfönster relaterade till databasadministratören körs mitt på natten när de sover, så de måste ha möjlighet att gå tillbaka och se vad som hände . I många fall, om du inte fångar något när det händer, när problemet har försvunnit, eller åtminstone med SQL Server, blir det ett slags problem där du hanterar situationen där du inte har några rester av det problemet längre. Och dessa problem försvinner, och det gör även resterna, vilket innebär att du har mindre att felsöka, du har mindre information att arbeta med.

Med det sagt är det definitivt en av de saker som Diagnostic Manager kan hjälpa till, är att ge dig den åsikten i det förflutna för att fråga informationen från det förflutna, "Hade jag en varning om att blockera, hade jag problem med deadlocking, hade vi saker som hände när det gäller våra resurser? ”Jag kan gå tillbaka och fråga informationen. Jag kan borta i specifika punkter i tid. Jag skulle kunna göra alla dessa saker direkt från verktyget.

Alla dessa saker, trots att det är internt eller externt, DBA vill veta, för de vill kunna se vad som orsakar problemet. Det spelar ingen roll om det var någon inne i organisationen, eller någon utanför organisationen som skrev koden; de vill fortfarande kunna isolera det så att de vet att problemet händer och de vet var det kommer ifrån.

Så prestanda och ansvarsskyldighet är en viktig del av vad vår produkt gör. Vi kan tillhandahålla alla dessa detaljer, och vad som är trevligt, är att du har möjlighet att borra ner. Om det finns en flaskhals kan du korrelera det med applikationen, användaren, databasen, frågan. Och ännu en gång är det en rökningpistol. Du får en direkt korrelation mellan när den här frågan körs, vad gör den? Och det handlar inte bara om själva frågan, i termer av att den körs i sig själv, utan också blir frågan med tiden värre? Och de sakerna kan också besvaras med produkten, som definitivt är något som om du försöker vara proaktiv, är det trevligt att kunna säga, "Hej, här är en fråga som gick dåligt, men pojke titta på det när det går längre kan vi se att det går ännu värre och värre, jag kan göra något åt ​​det. "

Om vi ​​går in i nästa område här; och det är förmodligen - jag skulle säga att det här är en av de stora. En av frågorna jag ställer, när jag visar vår produkt är, kommer jag alltid att ställa databasadministratören, "Hur hör du till ett problem relaterat till dina SQL Server-databaser?" Och det är väldigt roligt, för det mesta av tiden - nu beviljat, för det mesta tittar de på vår produkt, för i många fall försöker de lösa ett särskilt behov. Men det är intressant att höra den ursprungliga typen av saker - åtminstone med SQL Server, är att det var typ av det - du vet, i början av SQL Server hade du SQL Server och sedan hade du Oracle. Och alla hade Oracle, och SQL Server var på samma sätt som på grund av brist på ett bättre uttryck, det rödhåriga stegbarnet för databaser, när det först startade.

Och sedan när Microsoft lagt till fler funktioner till det blev det lite mer ett företagsverktyg. Och uppenbarligen har det kommit långt sedan dess. Men poängen är att man en gång kunde hävda att databaserna inte ansågs vara så kritiska på dagen. Och det har förändrats över tid. På grund av detta försöker människor i många fall ta hand om det och säger: ”Vet du vad? Jag har alla dessa SQL Server-databaser, jag försöker få tag på det. "Och snarare än att höra om problem från helpdesk eller att höra om problem från specifika personer som - som användarna själva, de" De letar efter några sätt att gå runt på. De letar efter sätt att kunna bli medvetna om dessa situationer innan de någonsin inträffar.

Och så med Diagnostic Manager, det är en av sakerna, vi försöker göra också, är åtminstone kunna göra att DBA är den första att veta om dessa situationer eller dessa problem, så att de kan göra något med det, antingen rätt när de händer, eller ta det ännu ett steg längre, för att analysera dessa system som den övervakar. Och för att kunna ge dig proaktiva råd som kommer att förbättra prestandan i den instansen och att kunna göra det regelbundet. Till exempel måste vi lägga till ett index, baserat på arbetsbelastningen; dessa typer av saker, de verktyg som kan göra också. Så vi får se mycket av det i verktyget.

Det andra och det sista som finns på den här listan, som är mer generell beskrivning, men det är definitivt värt att notera. Och särskilt när du kommer in i de större typerna av företagsnivåer, där du har många fall, kommer det alltid att vara något oklart som jag kommer att vilja övervaka, om jag är databasadministratören, för exempel. Och vad vi försöker göra är att förutse vad den typiska DBA kommer att vilja övervaka.

Med det sagt kan du också göra det - det kommer alltid att finnas något nytt. Så vi tillhandahöll ett sätt för dig att lägga till alla mätvärden du behöver för att övervaka och hantera efter installationen kan läggas till. Så alla PerfMon-räknare, WMI-räknare, SQL Server-räknarobjekt; alla dessa kan integreras i verktyget. Du har möjlighet att lägga till ytterligare frågor som kan integreras i dina omröstningsintervall.

Och det sista som också är värt att notera är att vi kan lägga till och faktiskt kommunicera med både vCenter och Hyper-V för att kunna dra statistiken från dessa miljöer. Eftersom en av de saker vi har identifierat med DBA är att de vanligtvis inte ingår i verksamheten specifikt. Och de behöver inte nödvändigtvis vCenter-miljön, tillgängliga för dem, eller sådana saker som finns tillgängliga för dem.

Och så är problemet att om de har att göra med en SQL Server-instans, och de har tilldelats resurser, men den instansen är virtualiserad, kan det se ut som om de har alla resurser i världen, när de bara övervakar vad som är på gästoperativsystemet. Verkligheten är att det på värden kan finnas 30, 40, eller 50 eller 100 andra VM: er som de försöker få tillgång till och har strid om samma resurser. Och det enda sättet att faktiskt se det är att kommunicera med de andra miljöerna och de gränssnitten, i det här fallet, vilket vi gör.

Du har möjlighet att lägga till dessa andra typer av räknare i verktyget. Nu handlar det inte bara om att kunna övervaka dessa räknare, utan det handlar om att kunna göra de nya räknarna, att du introducerar till produkten, gör dem till en del av verktyget, som om de var en out-of-the-box metrisk . En out-of-the-box sak som du vill övervaka; så det betyder att kunna integrera dem i sina instrumentpaneler. Det innebär att du kan lägga till dem i dina egna anpassade rapporter, att självklart kunna ställa in trösklar och varna på dem, men också baslinje dem och kunna ställa in trösklarna med viss kunskap, var du ska ställa in dem baserat på saker som din baslinjer och vad som är normalt. Så du har många sådana saker som också finns i produkten.

Det jag har gett dig är det jag kallar "de viktigaste leveranserna för Diagnostic Manager", och jag kan gå vidare och bara ge dig en liten smak av det genom att gå in i produkten. Vad jag ska göra är dela ut min skärm, okej, och bara kommer att dra det här över. Så vad du ska se, det här är konsolen för Diagnostic Manager. Och som jag nämnde tidigare, gå till den första kärnan som kan levereras, att kunna titta på saker från en typ av företagsnivå. Det finns många olika exempel på det i verktyget. Vi har en slags miniatyrvy, vi har mer en rutnätliknande vy. Vi har också, när det gäller flexibilitet, vi ha en webbaserad konsol också. Den webbaserade konsolen har andra vyer som är tillgängliga för dig, som nyckelkartor och liknande saker. Men poängen är att du har den förmågan att titta på och se saker. på hög nivå. Men när problem uppstår kommer du att gräva lite längre ned i verktyget och faktiskt se det specifika problemet lems, och har något sätt att förstå och veta vad som händer. Och det är uppenbart mycket viktigt.

Nu när det gäller att faktiskt kunna se vad som hände tidigare; om jag tittar på ett problem som hände igår, eller för en vecka sedan, då, i den situationen, du vet, kommer du att behöva kunna gå ut till en viss instans av SQL. Och de goda nyheterna är att om du vet vilken tid det problemet har hänt inom produkten kan du gå direkt till historikwebbläsaren. Och jag kan peka på en specifik tid på dagen; Det kan vara från ett par veckor sedan, det kan vara från igår. Men oavsett vilken dag jag väljer i kalendern, kommer jag då att presenteras med olika valmöjligheter. I vilket fall nu ser jag effektivt vad jag skulle ha sett om jag hade tittat på konsolen den 20 april kl. 1:37

Så jag kan gå tillbaka i tiden och sedan när jag gör det kommer alla de olika flikarna som vi ser här att återspegla den specifika tidpunkten, inklusive frågor som kanske har kört dåligt, inklusive kanske om Jag hade sessioner med blockering. Alla sådana saker skulle dyka upp i verktyget, och det kommer att göra det möjligt för mig att uppenbarligen utnyttja den historiska informationen för att du ska kunna fixa problemet. Nu när vi pratar om historien, är det andra som är värt att notera här att det inte bara använder historiken för att fixa problem. Den historien är uppenbarligen mycket värdefull av andra skäl. Och en av de stora är att kunna fatta beslut effektivt och kunna fatta beslut snabbt med rätt information. Så all den historien, all information vi samlar in kan vi rapportera mot.

Om någon kommer till mig och säger, "Jag fick den här riktigt bra nya applikationen. Det kommer att förändra världen så som vi känner den. Åh, förresten kräver en databas, och åh förresten kommer den verkligen att fixera I / O på maskinen där databasen finns. " Om jag vet att det går in på det, så kan jag utnyttja den informationen för att kunna ge en ranking av alla mina produktionsservrar, kanske baserat på de sju sista dagarna av insamlingen. Och jag skulle mycket snabbt kunna komma till slutsatsen i vilka fall som är mest förnuftiga att använda den databasen på. Så det är den typen av historisk information som också är uppenbarligen mycket värdefull.

När det gäller själva frågorna; när det gäller att titta på frågorna har vi många olika sätt att göra det i verktyget. Och den jag gillar att titta på är Query Waits View, eftersom Query Waits View är till stor hjälp när det gäller att kunna bedöma. Om jag har en flaskhals som inträffar, för att kunna identifiera alla de olika områden som påverkar den specifika frågan; inte bara själva frågan och vilken inverkan den frågan har, utan också, du vet, vilken applikation den kom från, vilken session den kom från, vilken användare som kallade den och alla dessa saker, jag kan se uppenbarligen information i realtid, men jag har också förmågan att titta på data från det förflutna. Och så det är en av sakerna här, och jag startade ett manus, men jag måste vänta på att det ska dyka upp.

Medan vi väntar på det vill jag göra det - och jag vet att vi är kort i tid, så jag ville lite prata lite också om att varningsmeddelanden är proaktiva. Och när du pratar om den typen av saker, som jag sa, som den proaktiva delen, finns det många verktyg som gör varningar. Den hårda delen är inte att skicka ett e-postmeddelande. Den hårda delen är inte att skriva till händelseloggen eller generera en SNMP-fälla. Den svåra delen är att veta när man ska skicka den varningen vid lämpliga tidpunkter. Och så med det kommer mycket att behöva göra några beräkningar, att behöva förstå, "Vad handlar det om den speciella instansen och vad är normalt när det gäller den instansen?"

Och så för alla mätvärden som är vettiga att göra det baserar vi dessa mätvärden. Vi visar dig faktiskt baslinjen, vi visar dig tröskeln som den för närvarande är inställd på. Och det andra trevliga med det, är att låt oss säga, jag ställer mina trösklar till i detta fall sex och tio bara för detta exempel. Sex veckor från och med nu, om jag kommer tillbaka till det här fallet, kan denna baslinje helt förändras, eftersom en av de saker vi gör när vi beräknar baslinjen, som standard, är en rullande sjudagarsberäkning. Så det ger mig alltid en aktuell version av baslinjen. Och vad händer om den baslinjen växlar upp i mina trösklar? I det här fallet kan jag se och varna rekommendationer som i princip säger: "Hej, du har en tröskel som förmodligen är felaktig, specifik för var vi ser tröskeln vara, och uppenbarligen var baslinjen är, kommer du förmodligen att få en varning för något som är normalt. "

Och så snarare än att behandla ett symptom på något som är normalt, kan jag identifiera den typ av situation där den faktiska tröskeln är felaktig. Och det som tillåter mig uppenbarligen är att ställa in trösklarna i enlighet med var jag ska få en varning. Det är något jag vet är mer en uppmaning till handling mot en utredning för att se om det verkligen är ett problem. Och jag tror att en del av verktyget verkligen är bra när det gäller själva baslinjen och att kunna beräkna.

Nu med denna produkt har du förmågan att faktiskt ha flera baslinjer; du kan ställa in dem för olika tidsperioder, och du kan dynamiskt justera trösklarna baserat på dina baslinjer, vilket också är mycket viktig del av typen av anpassning till de förändringar som sker dagligen till dina SQL Server-instanser . Nu, i det här fallet här, täcker vi en hel del inställningar för trösklarna och visar dig baslinjerna. Men när det gäller de faktiska varningarna är själva meddelandet, det coola med Diagnostic Manager, att det ger dig flera varningsprofiler. Så om du till exempel har en on-call-profil som är från 02:00 till 05:00, kan jag ha en profil som är specifik för just det tidsintervallet, och jag kan ställa in alla villkor och lämpliga inställningar här för mitt svar.

Nu är saken med svaret att jag i vissa fall kan skicka ett e-postmeddelande, eller jag kan skjuta av och generera en SNMP-fälla eller skriva till händelseloggen. Det finns många andra saker vi kan göra, men när jag pratar med DBA är det faktum att i de flesta fall är mycket av det arbete som utförs repetitiva grejer. Det är saker som de vet exakt när problemet händer, vad de ska göra för att fixa det. De måste bara gå och ingripa. Och så när du växer din miljö, när du har fler fall, blir det mycket svårare att göra. Så en av de saker du kan göra i verktyget som jag tycker är värt att notera, är att du har förmågan att skapa ett villkor, men baserat på det villkoret för att kunna ställa in ett svar för att köra ett skript, att köra ett jobb, för att köra en körbar. Och poängen är att om du bestämmer dig för att köra ett skript kan jag använda parametrar, inuti det skriptet som kommer att vara vid körningstid, fyllt med den faktiska informationen.

Så om det finns problem med en specifik databas kommer skriptet att utformas så att det körs bara mot databasen där problemet händer. Så du kan dynamiskt ta itu med problem på ett automatiserat sätt, och sedan kan jag fortfarande få ett e-postmeddelande för att komma tillbaka och säga att "Hej, det var ett problem, men förresten, det var fixat." Manuset kördes, och som DBA vet du om det, men du behövde faktiskt inte gå in och ingripa. Nu, på samma anmärkning om att vara proaktiv, har vi uppenbarligen också en annan funktion här som är "Analysera" -funktionen. Och vad detta kommer att göra är att det kommer att göra en regelbunden kontroll mot förekomsten av SQL. Och i vissa fall kommer det att göra ett djupare dyk när det gäller vad det letar efter. Saker som hypotetisk indexanalys kommer att utföras. Läggar jag till ett index? Tar jag bort ett index? Och alla dessa typer av saker kommer uppenbarligen att hjälpa till med min prestanda, men än en gång handlar det om att vara proaktiv. Det handlar om att kunna fatta beslut innan saker går sönder och att göra det bättre. Och så i många fall är det verkligen vad vi försöker göra här.

Gå tillbaka till fråga Väntar på att vi pratade om tidigare; som ni ser finns det en stor spik här. Jag körde ett manus tidigare som bara orsakade lite väntaaktivitet, och som jag nämnde tidigare har vi ett riktigt unikt sätt att du kan gå in i den här informationen. Om jag vill se vilken applikation det var; Jag kan se att det kom från NoSQL-applikationen. Vi skulle kunna se databasen den var bunden till, sessionen, användaren, och om jag vill, så kan jag också ranka detta, både vad gäller mina väntningar. Så, jag kan säga, av alla de väntningar som hände i det där tidsfönstret, vilka som hände mest? Och om jag ser att när det hänt mest är det riktigt trevligt att jag kan borra in i den väntetypen och jag kan se alla kommandon. Om du tittar här fick de att vänta inträffa. Och jag kan också se främst, vilken applikation det var, som fick den väntan att inträffa.

Så det sticker ut som en öm tumme. Jag kan genast gå och säga, "Det här är applikationen som orsakar min flaskhals. Nu vad var frågan som kördes? Vilken användare körde den? Vilken databas körde den mot?" Och så vidare. Så förhoppningsvis är det meningsfullt, och det hjälper också när det gäller att se till att du inte har fördröjningen i din miljö, eftersom den hänför sig till dina databaser. Förhoppningsvis är det till hjälp. Jag kommer att gå vidare vid denna tidpunkt och skicka den tillbaka, och jag antar att vi kan fortsätta därifrån.

Eric Kavanagh: Visst. Så jag antar att jag bara kommer att kasta det till dagens experter. Markera, kanske först vill du kommentera och ställa ett par frågor. Sedan Dez, kan du chime in.

Mark Madsen: Ja, tack, jag gillade verkligen att titta på något av detta. Det är en mycket mer intelligent övervakning än jag är van vid att se. Jag är nyfiken på att hantera uppgifterna bakom detta; hantering av mätvärden som du kan spåra, och du vet, leta efter saker som att skifta baslinjer i synnerhet, att vara en av mina smärtapunkter för husdjur, med instrumentpaneler. Hur hanterar du den informationen, och den andra delen av detta är med, du vet, baslinjemetriker, som en typ av skift - har du förmågan att automatiskt ändra trösklarna också, så att jag inte behöver gå tillbaka in och återställa trösklar för hand när en baslinje förskjuts?

Bullett Manale: Det gör du, och det trevliga med det är att du kan bestämma det. Du kan göra det heller. Jag kan ställa in en tröskel och göra det till en statisk inställning, eller jag kan kryssa i rutan för att säga "Gör detta till en dynamisk tröskel, som kommer att ändras när mina baslinjer förändras." Och jag har förmågan och verktyget att ställa in ett standardfönster tid för min baslinje. Men om jag behöver det, kanske jag har ett separat baslinjefönster, till exempel från mitt underhållsfönster från 02:00, låt oss säga till 05:00, eftersom jag kommer att beskatta mina CPU, mina enheter och allt annat eftersom det är när vi gör allt vårt underhåll. Det skulle då automatiskt, om jag hade valt att göra det, skulle det automatiskt justera mina trösklar så att de ligger utanför där det som är normalt för de mätvärden som Jag väljer att göra det med. Det skulle tillåta mig att göra det. I princip har du en förmåga inom verktyget att ställa in tidsfönster, det är dina baslinjefönster, och varje fönster kan behandlas som en separat enhet, i termer av dynamisk baslinjeanpassning som kan göras.Och du kan lägga till så många fönster i din baslinje som yo u måste, om det är vettigt. Du kan ha ett helgfönster, en vardag under arbetstid, ett underhållsfönster som händer mitt på natten och så vidare.

Mark Madsen: Tack.

Bullett Manale: Jag antar att jag kommer tillbaka till den första delen av frågan, vi har, och samlar all denna information. Jag pratade inte riktigt om arkitekturen, men vi har ett back-end-arkiv, att du har fullständig kontroll över lagring av dessa data, men vi har också en tjänst som kör mitt på natten som går och gör alla våra basberäkningar och det tar den informationen, samlar in och förstår det. Och självklart har du också många rapporter som vi kan använda för att rapportera mot dina baslinjer för specifika statistik. Och du har till och med förmågan att jämföra dina baslinjer på samma server för samma metrisk under olika tidsperioder. Du kan se om det finns skillnader som har inträffat eller vad deltaet är. Det finns många av dessa typer av alternativ också.

Eric Kavanagh: Dez.

Dez Blanchfield: En snabb fråga jag har till dig - det finns ett brett spektrum av vad det här verktyget kan göra. Ser du ett upptag i användningen av det i det tidiga utvecklingsstadiet nu, eller är det fortfarande främst ett produktionsmiljöverktyg? Med andra ord, får utvecklare åtkomst och använder det genom sin tidiga utveckling och testar sedan integrationsfasen? Eller används det fortfarande främst i produktionsmiljöer?

Bullett Manale: Jag skulle säga det, för de flesta gånger vi ser det i produktionsmiljöer. Det beror på situationerna, men för det mesta skulle jag säga främst produktion och vi gör - och det är också, du vet, rättvist att nämna att vi har olika priser för dev- och testmiljöer, så det är lite mer attraktivt. Vi ser människor som använder det för dessa miljöer men jag skulle säga, om jag var tvungen att ge dig ett svar på ett eller annat sätt, skulle jag säga att det främst fortfarande är produktionsmiljöer där vi ser att människor gör en investering för den här produkten .

Dez Blanchfield: Visst, ja, och det var intressant att höra att du har olika prissättningspoäng, för uppenbarligen finns det olika arbetsbelastningar, och desto tyngre jobb kommer att vara där allt verkligt arbete görs. Men jag ser många organisationer, särskilt i regeringen och säkert i försvar, där utvecklingen nu får samma nivå av investeringar i verktyg och system som produktionsmiljöer, eftersom de gör mycket mer tester i förväg. Som försvar finns det till exempel lag som kör miljarder tester, hundratals miljarder tester på applikationer och system och verktyg och övervakar dem innan de ens går in i integrationstest, eftersom de vill se till att det finns en kod som är inbyggd och databasen det sitter under det. Det kommer till en hundra och en miljon iteration eller något, medan du är ute i fältet och skjuter på någon, går det inte "bang".

Bullett Manale: Visst.

Dez Blanchfield: I min gamla erfarenhet av databasvärlden i gamla skolan, att tänka att databasmiljön är något som bara har kvar i data och några av er vet, är mycket sällan sett och mycket sällan talas om, så när vi nu får poängen där verktyg och appar utvecklas, särskilt med analytiska plattformar, de finns nu i våra telefoner och våra enheter. Ser du klienter ta med sig konversationen av databasprestanda och databashantering i en mer daglig diskussion i motsats till bara rent teknik? Och jag vet att du nämnde tidigare att övervägande talar du med DBA, men finns det en trend nu där det är i det allmänna ordförrådet, ser du människor där de diskuterar dessa ämnen, i motsats till bara nördar?

Bullett Manale: Det är tufft att säga. Jag menar, som jag sa för det mesta, att de människor som vi hanterar i fråga om försäljningsprocessen ändå är med utövarna, som är DBA. Så när det gäller din fråga säger du bara "I allmänhet, människor inom IT-organisationen, blir de mer databasmedvetna?" Jag antar att det är frågan och jag skulle säga att svaret är "ja." Jag ser det förmodligen inte så mycket, baserat på var jag är, på en daglig basis, men jag tror att om jag förstår din fråga skulle det vara mitt svar, antar jag.

Dez Blanchfield: Ja, det är okej. Det är förmodligen en laddad fråga, ledsen, för uppenbarligen är dina dominerande intressen i din värld den tekniska sidan av saker. Jag är nyfiken på att jag i min dagliga verksamhet ser organisationer börja ta in detta i konversationen mycket tidigt. Så när de pratar om nya initiativ, nya projekt, nya arbetsprogram, en av de saker som kommer omedelbart är: "Hur övervakar vi det, hur spårar vi det, hur hanterar vi frågor när de uppstår, i motsats till att lansera, gå live? "

Bullett Manale: Jag skulle säga det -

Dez Blanchfield: Tyvärr, fortsätt.

Bullett Manale: Jag skulle säga att jag ser en trend som jag antar att jag borde säga i - du vet, många gånger i det förflutna du skulle få, "Vi hade ett problem, och nu behöver vi ett verktyg. " Och jag tror att vi ser lite mer av acceptans kring att ha verktyget på plats innan problemet inträffar, om det är meningsfullt. Så jag skulle säga att det definitivt blir mer normalt att bli, du vet, "Hej, vi behöver ett övervakningsverktyg, vi behöver något." Och människor ser definitivt värdet på denna produkt, för som du sa tidigare, bara lägga till DBA och lägga till nya instanser, du behöver något som hanterar det. Du behöver något som hjälper till med hanteringen av det, och det är därför vi ser mycket acceptans kring denna produkt också, eller vi har.

Dez Blanchfield: Snabb fråga. Var behöver detta bo? Måste det sitta på baksidan bränna på LAN, i datacentret, så nära databasmiljöerna som möjligt, eller är det bekvämt placerat någonstans, eventuellt ute i molnet, ett tredje parts moln med något slags antingen VPN-tunnel eller fjärråtkomst till olika miljöer? Var måste det sitta när det gäller miljöer och övervakning?

Bullett Manale: När det gäller arkitekturen finns det ett back-end-arkiv, och det är en SQL Server-databas. Vi har konsolen som antingen kan vara en fet klient eller en tunn klient; vi ger dig möjligheten att båda. Och vi har också en tunn klient som också verkligen är anpassad till mobila enheter. Men när det gäller var detta faktiskt kan sitta; det kan sitta i en miljö, verkligen den svårare delen med det, från mycket av den information vi behöver samla in, kräver administrativa rättigheter, i vissa fall eller i många fall. Nu får vi inte göra dig; om du vill kan du samla in data och bara för de saker vi inte kan samla in, eftersom vi inte har administratörsrättigheter, vi låter dig bara inte se den informationen, om det är det val du gör.

Beroende på smaken, som om du pratar om AWS, fungerar vissa miljöer bättre än andra, men vad gäller själva miljön, vanligtvis antingen med SA-verifiering för att samla in data mot instanserna är allt som behövs. Eller om det är en opålitlig domän, är det vanligtvis när du vill göra det, men flera domäner; så länge det finns ett förtroende mellan dem kan vi samla in mot dem. Det spelar ingen roll om det är på ett LAN eller om det är i WAN, själva samlingen är ganska försumbar när det gäller mängden data vi samlar in. Om vi ​​har tillräcklig WAN-anslutning är det inte ett problem. Jag har sett miljöer där de har filialer där de har SQL-servrar över hela USA. Och det är en server på var och en av dessa olika platser, och de övervakar den centralt. Den svåra delen är bara att se till att du har en anständig mängd anslutning för att göra det. Förhoppningsvis, som svarar på din fråga, det var typ av hela kartan.

Dez Blanchfield: Det gör det, absolut. Tack. Så, två snabba frågor som har kommit genom deltagarna i morgon; det ena är: vad är effekterna av - ofta ser vi systemövervakningsverktyg generera belastning själva genom att bara övervaka saker, så frågan var, ledsen det rullade bort från min skärm nu, men för att bara parafrasera det; genom att övervaka genererar vi belastning själva? Finns det en mätbar påverkan av verktyget, bara att titta på miljön, eller är det en försumbar inverkan?

Bullett Manale: Det kommer alltid att ha en liten inverkan eftersom det måste fråga SQL Server-instansen för att dra tillbaka data. Frågan som du sa är "Är den försumbar eller är den betydande?" Ut ur rutan som du pekar på en instans är det försumbar. Vi har gjort detta för, som sagt, ganska länge nu. Vi har över 20 000 kunder, och jag kan försäkra er att om det orsakar betydande resultatpåverkan, skulle vi inte vara i affärer. Med det sagt tillåter vi också användaren att bestämma vad de vill att de vill övervaka. Så jag tror att det är en viktig sak att nämna, är att varje miljö är lite annorlunda.

Ett exempel skulle kunna vara, med frågaövervakningskomponenten, en av de saker vi har förmågan att göra, är att vi kan ställa in tröskeln för vad du anser vara din normalitetsgräns. Så det kan baseras på tidpunkten för genomförandet av frågan. Det kan vara baserat på CPU, I / O, men som ett exempel, låt oss bara säga att jag har ställt in min tid på exekvering till noll millisekunder. Det jag säger till verktyget att göra är effektivt att samla in alla frågor som gick sedan det senaste dragintervallet och göra den del av min historiska samling också.

När vi gör det kommer vi att samla in mängden frågor vi körde på lådan sedan den senaste valmöjligheten. Nu är det valbart, och användaren har förmågan att göra det. Säger vi, "Det är vad du bör göra"? Nej. Men vi ger dig också möjligheten att göra det om du vill ha ett urval av data som låter dig samla in den informationen. Så generellt sett har du medel inom verktyg för att ställa in det och ställa in det exakt hur du vill baserat på vad du är bekväm med. Men du har förmågan att verkligen öppna den om du vill, och samla in massor av ytterligare information som du kanske inte nödvändigtvis regelbundet samla om det är meningsfullt.

Dez Blanchfield: Ja, absolut. Jag vet att vi springer lite länge, men det finns två riktigt fantastiska frågor som jag vill kasta till dig innan jag går ihop. De kommer båda direkt till mig, men jag tycker att det är bäst om du svarar på dem. Frågan var i allmänhet: "Hur omfattar verktygets räckvidd såvitt kunskap om befintliga system?" Så kan vi bara ansluta detta och låta det automatiskt upptäcka den plattform som finns där, och veta vad som är normalt för den plattformen, och omedelbart plocka upp som Mark talade om tidigare? En del av baskunskapen om plattformarna genom att sätta in, du vet, jag vet inte, det kan vara Microsoft Dynamics. Vad är omfattningen av kunskapen om plattformen med vad som är normalt och i några av de nuvarande verktygen som används runt företaget?

Bullett Manale: Jag skulle säga att när vi börjar samla in data på SQL-instansen arbetar vi med bästa praxis till att börja med, när det gäller våra trösklar och var de är inställda på. Som sagt, vi inser också att den som du pratar med, i fråga om bästa praxis, varje miljö är annorlunda. Vad vi kommer att göra inledningsvis samlar vi bara in uppgifterna, och vad vi rekommenderar att människor gör, du kan prova produkten i 14 dagar längre om du behöver. Men efter ungefär två dagar börjar du se basdatadata. När den har tillräckligt med provinformation att arbeta med, kommer den att börja ge dig sammanhanget i termer av baslinjen, var intervallet är och allt det där. Därifrån, om du vill, kan du automatiskt ställa in dina trösklar från den information som har samlats in. Det krävs lite inledande insamling och polling för att kunna börja bestämma vad som är normalt, så att du kan börja flytta dina trösklar.

Men det som jag tycker är värt att notera också är att när du ändrar dessa tröskelvärden kan det göras grupp för grupp av dina instanser. Det kan vara specifikt för en instans eller så kan du göra det mot alla dina instanser, liksom möjligheten att skapa saker som mallar, så att du kan säga "Detta är en produktionsinstans, men det är den mall som jag vill ha att tilldela den. " Och så när en ny produktionsinstans kommer online, tillämpar vi automatiskt dessa trösklar för den, eftersom den har samma typ av hårdvara, och den brukar ha samma arbetsbelastning, så vi skulle kunna göra det på det sättet också. Förhoppningsvis hjälper det i fråga.

Dez Blanchfield: Det gör det, absolut. I själva verket svarade du faktiskt på en annan fråga som just kom in till mig, och det var: "Finns det en nedladdning av rättegången?" Det finns, jag kan svara på det, jag vet. Jag är säker på att du kommer att bekräfta att det finns en gratis nedladdning, och jag tror att du sa att det var 14 dagar från webbplatsen. Du kan ladda ner den och spela med den. Jag antar dock bara snabbt med det: "Vilken typ av miljö behöver jag för att kunna köra testversionen? Kan jag köra den på min bärbara dator och spela med den eller behöver jag verkligen en server?"

Bullett Manale: Det viktigaste det är ett förvar, en SQL Server-databas som är 2005 eller högre. Utöver det finns det några minimala resurskrav, ett .NET-krav, och det är det. Så det handlar bara om att installera produkten och skapa en databas.

Dez Blanchfield: Perfekt. En sista fråga som jag kommer att kasta på dig, för vi är precis ute på tid nu, men snabbt frågade ungefär två eller tre personer mig, "Måste jag vara en DBA för att faktiskt kunna komma igång med detta och ha en lek med det? ”

Bullett Manale: Nej. Jag skulle säga att om du är en DBA kommer du att ha olika användningar av verktyget. Jag menar, det kommer förmodligen att bli lite mer värde om du är en rutin DBA. Du kommer att se mycket mer djup till det verktyg som du skulle kunna dra nytta av. Men också som en ny DBA, eller ens en person som, det är inte en DBA, vi har många rekommendationer, och jag är på den sidan just nu. Dessa rekommendationer kommer upp regelbundet, och det riktigt bra med rekommendationerna är att de ger dig orsakerna till att rekommendationerna görs. Men utöver det kommer de också att ha länkar till externt innehåll som beskriver mer detaljerat om skälen till att dessa rekommendationer också görs. Så det kommer att länka till externa Microsoft-webbplatser, bloggar och alla slags sådana saker, det är externt.

Men för att svara på din fråga är det typ av, du vet, om du är en senior DBA, kommer det att finnas saker här inne, kommer du förmodligen att dra nytta av, som du förmodligen inte skulle som en nybörjare DBA. Men då är det också ett lärande verktyg, för när du går igenom dessa rekommendationer börjar du plocka upp några av dessa saker på egen hand genom att använda rekommendationerna.

Dez Blanchfield: Fantastiskt. Tack. Jag gillade demo-delen verkligen. Presentationen var fantastisk. Demon var fantastisk. Snabbt från minnet finns det ett helt resurscenter på din webbplats som jag rekommenderar att folk också tittar på. Jag minns att jag gick igenom i går kväll för att få några detaljer. Du har en hel rad saker, bara från dina bloggar och data och konversationer till, från minnet, du har det mesta av din produktdokumentation online också, ja?

Bullett Manale: Ja, det är korrekt, och den form som jag tror att du refererar till är community.idera.com-webbplatsen. Och sedan skulle jag också nämna en sak, tidigare har du frågat om "Kommer det att känna igen miljön?" När det gäller nya instanser eller lägga till instanser finns det ett annat verktyg som vi har som upptäcker instanser. Och det handlar om inventering och hantering av ditt lager. Jag skulle bara peka dig i den riktningen, när det gäller att faktiskt upptäcka fallen. Men vad beträffar prestanda och övervakning, allt det där vi pratade om, det var där Diagnostic Manager skulle komma in.

Dez Blanchfield: Fantastiskt. Titta, bra täckning. Gillade verkligen din presentation. Älskade live demo och det är allt från mig i morse, eftersom jag vet att vi antagligen har gått 10 minuter över tiden. Eric, jag kommer att gå tillbaka till dig.

Eric Kavanagh: Okej. Jag älskade bara demot. Jag är glad att du gjorde demot. Jag är glad att vi fick ta en tuff hård titt på det när vi gick igenom frågor och svar.

Bullett Manale: Bra .

Eric Kavanagh: Eftersom detta ger människor en uppfattning om vad du tittar på, och det verkligen förvånar mig något att tro att vi fortfarande lär oss hur man pratar med dessa datorer, när du kommer till det. Jag menar, den här nivån av diagnostik är ganska sofistikerad och den blir bättre varje dag. Vi får mycket mer inblick i vad som faktiskt händer. Men du behöver verkligen en person som förbiser det här, läser det, lägger den kognitiva förmågan bakom det du gör, eller hur?

Bullett Manale: Ja, jag menar i många fall - jag önskar att jag kunde säga att det här är en DBA i rutan, men det finns bara för många saker som pågår. Jag menar, vi ger vägledning och vi hjälper till, men i slutet av dagen kräver det att människor fattar beslut om de uppgifter som vi presenterar. Jag tror inte att det kommer att förändras snart.

Eric Kavanagh: Det är bra nyheter för de riktiga människorna där ute, folkens.

Bullett Manale: Det stämmer.

Eric Kavanagh: Du kommer att vilja ha någon som tittar på detta, ett team som tittar på detta, och du kommer att lära dig, som du har hört från Bullett här, titta på dessa rekommendationer du kommer att ta upp vad som händer. Och jag gissar från den historien, och jag tror att du har berört detta, Bullett, men väldigt snabbt, att historien gör att du kan känna igen betydande mönster och sedan kunna identifiera dem när de händer i framtiden, eller hur?

Bullett Manale: Det är korrekt. En av de saker vi kan göra är att spåra en frågs resultat över tid. Vi kan naturligtvis också titta på andra saker, som baslinjer och se dem växla, och uppenbarligen få varningar och sådant när det händer, så du har definitivt den förmågan.

Eric Kavanagh: Det låter bra, folkens. Vi skulle inte ha varit länge här, men jag ville komma till de frågorna. Tack så mycket för din tid och uppmärksamhet. Vi arkiverar alla dessa webbsändningar. Hoppa online till Techopedia.com eller InsideAnalysis.com, du ser länkar från båda platserna.

Och med det säger vi dig farväl. Tack igen, folkens, vi kommer att komma ihåg dig nästa vecka, ytterligare tre webbsändningar nästa vecka, tisdag, onsdag, torsdag. Så vi pratar med dig nästa vecka, folkens. Ta hand om dig. Hejdå.

Techopedia Content Partner

Techopedia Staff är anslutet till Bloor Group och kan kontaktas med alternativen till höger. För information om hur vi arbetar med branschpartner klicka här.

• Profil
• Hemsida