Door Techopedia Staff, 30 november 2016
Takeaway: gastheer Eric Kavanagh samen met Dr. Robin Bloor, Dez Blanchfield en IDERA's Bullett Manale bespreken vragen en hoe hun efficiëntie verstrekkende gevolgen kan hebben.
Je bent momenteel niet ingelogd. Log in of meld je aan om de video te bekijken.
Eric Kavanagh: Dames en heren, hallo en welkom weer terug. Het is woensdag om vier uur Eastern Time en tegenwoordig betekent dit dat het tijd is voor Hot Technologies! Ja inderdaad. We hebben het vandaag over coole dingen. Natuurlijk ben ik je gastheer, Eric Kavanagh. De titel voor de show van vandaag is "De sleutel tot effectieve analyse: snel terugkerende zoekopdrachten." Dat klopt, mensen, we willen allemaal snel. Wie wil er niet snel? Er is echt een dia over die van jou, en genoeg over mij. Sla me op Twitter, @eric_kavanagh. Ik zal daar graag contact met je opnemen en een gesprek hebben op sociale media. Het kan leuk zijn, praat gewoon niet over politiek.
Het is een warm jaar. We hebben dit jaar over verschillende analytische problemen gesproken, en het enige onderwerp voor vandaag is echt gewoon van cruciaal belang om de klus te klaren. Ik herinner me dat het waarschijnlijk vijf of zes jaar geleden was dat ik voor het eerst iemand de uitdrukking 'een gesprek met je gegevens' hoorde gebruiken, en hoewel het een beetje cheesy kan klinken, is het punt dat als je geen iteratieve ervaring kunt hebben met uw gegevens, als u uw vragen niet snel kunt wijzigen, nieuwe vragen kunt verzenden, antwoorden snel terug kunt krijgen, dan bent u niet in gesprek met uw gegevens en is het hele analyseproces afgebroken. Dat is niet goed.
Wanneer u een gesprek met uw gegevens voert, betekent dit dat u heen en weer kunt gaan, en naar mijn mening is dat wanneer u het inzicht vindt. Omdat je heel zelden de eerste keer met de perfecte zoekopdracht komt. Tenzij je de Mozart van analyse bent - en ik weet zeker dat die persoon daar is - zul je wat tijd moeten besteden aan het aanpassen, een dimensie toevoegen, proberen af te stemmen waar je naar op zoek bent .
Omdat, nogmaals, dit geen enorm zwoele omgevingen zijn waarmee we te maken hebben in de wereld van analyse; we hebben te maken met zeer onhandige omgevingen en zeer complexe en multidimensionale omgevingen. En dus is het hele idee van de webcast vandaag om te praten over hoe dat soort iteratieve interactie met uw gegevens mogelijk wordt.
We hebben drie presentatoren. In Hot Technologies hebben we natuurlijk, in tegenstelling tot Briefing Room, twee analisten; ze geven elk eerst hun take, dan komt de gast binnen, geeft hun presentatie, en we hebben een soort rondetafel. En u, ons publiek, kan daar een grote rol in spelen. Wees alsjeblieft niet verlegen; stuur uw vragen op elk gewenst moment in. Gebruik het vraag- en antwoordpaneel als je kunt, anders is het chatvenster in orde; Ik zal proberen beide tijdens de show te volgen. En we nemen deze op, dus als u iets mist of wilt delen met uw collega's, kom dan later terug. We plaatsen ze op Techopedia.com en ook op InsideAnalysis.com.
En daarmee ga ik de slimme mensen binnenhalen. Ik ga het overhandigen aan Dr. Robin Bloor. Laat me hem de sleutels geven, van presentator veranderen, en daar ga je. Robin, haal het weg.
Robin Bloor: Oké. Bedankt voor die intro. Ongeveer anderhalve maand geleden had ik een chat met een ontwikkelaar die eigenlijk een DBA is. Hij is niet echt een DBA - hij was een DBA bij een bepaald bedrijf en hij was de enige persoon die de vragen daadwerkelijk kon laten presteren. Maar hij werd het zat om dat te doen, want hij is echt een redelijk slimme ontwikkelaar. Dus ging hij weg.
En hij moet sowieso elke dag een paar dagen voor hen doen, omdat ze niemand konden vinden om zijn plaats in te nemen en ze hebben geen idee wat de database doet of hoe ze deze kunnen afstemmen. En ik dacht daarover een beetje na, en weet je, ze hadden niet echt een IT-afdeling, maar deze man ondersteunde ze. Eigenlijk was het meestal DBA-werk dat hij deed.
Voor geavanceerde databases - Oracle, SQL Server, DB2, al die grote, dure - is database tuning een zware klus. Het is ook een veilige taak. En de reden om dit te zeggen is dat het een veranderend landschap is. Ik zal dit een beetje doornemen. Weet je, relationele databases - meestal is het grote beeld, de relationele databases domineren nog steeds in populariteit. Ze zullen waarschijnlijk nog lang domineren. Ja, er zijn nu andere databases die meer zendtijd krijgen, maar weet je, als je echt kijkt naar wat er daar gebeurt, doet Oracle het meeste, Microsoft SQL Server staat op de tweede plaats en er gebeuren verschillende dingen in de cloud kan echter een uitdaging veroorzaken. Zij zijn de grote reuzen in het spel. En het zijn de databases die u zowel voor OLTP als voor datawarehouse-workloads kunt gebruiken. Alternatieven worden normaal voornamelijk gebruikt in analytische omgevingen, en dan wordt het normaal gesproken bepaald door de gegevens waarom we daarvoor kiezen in plaats van relationeel. Meestal doen mensen dat niet.
Bedrijven hebben de neiging om te standaardiseren op een enkele database. Ik kwam onlangs een bedrijf tegen dat meer dan 5000 exemplaren van Oracle had. En ik soort, de persoon met wie ik sprak van dat bedrijf, ik vroeg hen soort over de DBA's. Ze zeiden dat ze ongeveer 10 DBA's hadden en dat er ongeveer 30 databases werden verzorgd. En de rest, Oracle werd in het algemeen alleen als eindsysteem gebruikt. Er was heel weinig stress op de gegevens van de applicaties die ze gebruikten. Maar dat verbaasde me gewoon - 5000 exemplaren van Oracle.
En trouwens, ze hadden een Oracle-landgoedlicentie. Nou, weet je, bedrijfslicentie natuurlijk. Maar ze hadden ook andere databases, omdat applicaties soms een voorkeursdatabase hebben. Het was niet alsof Oracle het enige was. Vermeldenswaardig is dat noch Hadoop noch Spark eigenlijk een database is, en het zal nog lang duren voordat ze verwerven wat ik beschouw als een databaseregel. Goed voor datalinks, natuurlijk.
Met DBA-activiteiten - waarschijnlijk kan Bullett hier veel meer over zeggen dan ik - maar ik zal ze gewoon doornemen. Dit zijn waar ik meestal aan denk, weet je, wat de DBA doet. Ze installeren, configureren, upgraden, doen licentiebeheer. Ze doen veel ETL en replicatiewerk op de een of andere manier. Ze doen opslag- en capaciteitsplanning. Ze doen probleemoplossing of maken deel uit van het probleemoplossingsteam. Prestatiebewaking en -afstemming is vrijwel het grootste deel van hun activiteit, maar al deze andere dingen, het is niet klein, weet je. Beveiliging, ze zijn verantwoordelijk voor back-up en herstel. Ze zouden betrokken moeten zijn bij software testsystemen, en ze zouden betrokken kunnen zijn bij de gegevenslevenscyclus.
Prestatie. Toen ik een van deze jongens was. Toen ik databases draaide en afstemde, begreep ik het zo, weet je? Er is de CPU, en op de een of andere manier in onze tijd is de CPU vrijwel normaal gesproken inactief, omdat het een van de andere twee of th zou zijn - Nou, een van de andere knelpunten zou het probleem eigenlijk veroorzaken. Geheugen, thrashing en fragmentatie, of schijf, of schijf I / O-verzadiging, soms netwerkoverhead, als u op meerdere knooppunten van een netwerk werkt en u zou waarschijnlijk wat vergrendeling kunnen tegenkomen, waarschijnlijk.
Maar dat was de wereld zoals ik die zag. Ik heb onlangs een kijkje genomen op Oracle en het aantal afstemmingsparameters dat er in Oracle zijn. Het was meer dan 300. Weet je, en als je er echt over nadenkt, moet een DBA die echt weet wat hij doet een idee hebben waarom je er ooit mee zou rotzooien. Dus het is een ingewikkelde klus, weet je, en het is hierdoor gecompliceerder.
Weet je, op dit moment hebben we CPU's, maar je hebt … de CPU's bestonden al, GPU's op de CPU of met FPGA's op de CPU. Dus er is een soort kruising van wat er feitelijk gebeurt op een CPU. CPU's werden lang geleden multicore; eigenlijk was ik niet langer bezig met het afstemmen van databases toen dat gebeurde. Ik heb geen idee welk verschil het eigenlijk maakt, nu ik erover nadenk.
We hebben, weet je, 3D Xpoint en IBM's PCM verschijnen als een extra geheugenlaag, en we hebben SSD's, maar weet je, ze vervangen spinnende roest. Maar de SSD's kunnen variëren in snelheden. Met zovelen heb je parallelle toegang en het maakt ze ongelooflijk snel - bijna RAM-snelheid. En u hebt alle parallelle hardware-architecturen.
En dit is alles, weet je, de kosten dalen, wat echt een leuke zaak is, maar dit is allemaal aan het maken - weet je, als je de volgende release van een database neemt en dan begin je deze te implementeren op machines, zelfs sommige van dit, je hebt eigenlijk elk gevoel verloren dat je hebt voor het gedrag van de gegevens, omdat de latenties gewoon heel, heel anders zijn. En hier, weet je, je hebt vier lagen in plaats van drie lagen opslag.
Databaseproblemen. U krijgt database-entropie - prolifererende instanties zijn heel gebruikelijk. Databases die als kasten worden gebruikt, wat ik eigenlijk heb gegeven. Heel weinig databases zijn zelf-tuning, en degenen die beweren zelf-tuning te zijn, zijn eigenlijk niet zo goed, weet je. Maar het andere is dat heel weinig databases correct zijn afgestemd. Het is een zware klus, in staat zijn om workloads in evenwicht te houden. Ik bedoel, als u aan een database denkt, wat een database gedurende een periode van 24 uur doet, kunnen de werklasten heel, heel anders zijn. De database moet een bijzonder waar datawarehouse hebben.
En daarom is afstemmen geen triviale zaak, weet je, omdat je bezig bent met het afstemmen van parameters die moeten voldoen aan een hele reeks werkbelastingen gedurende een bepaald tijdstip. Het is eigenlijk een zware klus. En SQL moet worden afgestemd, met name voor SQL JOINs. Ze kunnen extreem veel middelen verbruiken. En als de database gestructureerde weergaven heeft, om eerlijk te zijn, zou je het gebruik hiervan moeten onderzoeken, omdat ze alles ongelooflijk sneller gaan maken. En dat vereist iemand die de workloads begrijpt en het SQL-verkeer begrijpt enzovoort.
En de meeste bedrijven hebben zeer weinig DBA's in dienst - erg duur. Ik heb redelijk grote bedrijven gekend met, zoals, drie jongens, weet je, een enorm aantal instanties. Echt, ze kosten veel, het is een zware klus in termen van de complexiteit. Ze hebben gereedschap nodig.
En ik denk dat dat alles is wat ik te zeggen heb. O ja. Laten we Dez doorgeven, kijken wat Dez te zeggen heeft.
Dez Blanchfield: Bedankt, Robin. Dit is een enorm onderwerp. Ik ga me houden aan de dingen waarvan ik denk dat ze in feite dagelijkse uitdagingen zijn waarmee we worden geconfronteerd. Want laten we wel wezen, er is een hele bibliotheek met boeken over dit onderwerp geschreven. Wie is niet naar een technische boekwinkel gegaan en heeft muren en muren van boeken gevonden die alleen zijn geschreven over het algemene onderwerp van databaseprestaties en database-afstemming en monitoring. En soms is het een geweldige manier om tijd te doden.
Het algemene onderwerp: prestatiequery's krijgen. Er zijn een aantal verschillende delen van de organisatie die bezighouden met dit onderwerp - op jouw eindgebruikersniveau, weet je, mensen zijn gewoon prestaties, dat dingen traag zijn. Draaiende wielen hebben een tijdje nodig om de vragen terug te krijgen. Aan de andere kant van het spectrum heb je mensen voor infrastructuur en netwerk- en opslagtechniek die in elkaar worden geslagen door databasespecialisten omdat dingen niet zo goed lopen als ze verwachten. En het is een zeer breed spectrum, in mijn ervaring, de dingen die ons leven in dat spectrum kunnen beïnvloeden.
Als je denkt, vanaf het fysieke, weet je alleen de computerruimte. Het heeft geheugen, je weet wel, RAM, als je wilt - schijfruimte, netwerk en alle bits eromheen. In deze ruimte hebben we, weet je, het slaat de gedachte op dat, zeg, weet je, het is beter om onbewerkte schijf of een JBOD te gebruiken en gewoon, weet je, de schijf zo snel mogelijk laten rijzen en de database sorteren van de gegevensbeschermingslaag. Andere mensen zijn grote fans van RAID, de overbodige reeks goedkope schijven, en hebben verschillende religieuze ervaringen met RAID 0, 1, 3, soms 5 en 6 verschillende soorten striping of replicatie op schijf, voor het geval de harde schijf defect raakt. Zelfs op opslagniveau en engineeringniveau hebben we nog steeds mensen met verschillende opvattingen en ervaringen op het gebied van prestaties, op het gebied van opslag.
Of het nu gaat om direct gekoppelde schijven en de servers zelf, of het is verbonden via een glasvezelkanaal met een opslaggebiednetwerk van een of andere vorm, of het nu is opgeslagen op een server ergens via iSCSI of het Ethernet is, bijvoorbeeld. En dat is voordat u zelfs echt naar de databaselaag gaat, waar, weet u, het soort dingen dat we als vanzelfsprekend beschouwen - weet u, gewoon dat in stand houden, zoals Eric schetste, weet u, wat we het gesprek met uw gegevens noemen . Gewoon in staat zijn om patronen en betekenisvolle patronen te identificeren waarvan we denken dat we erin kunnen duiken en naar prestatieproblemen kunnen zoeken.
En het is een heel breed onderwerp, dus ik ga duiken in twee gebieden waar, naar mijn ervaring, tijd en energie en moeite geïnvesteerd een goed rendement oplevert. Dus laat me snel naar de eerste hiervan gaan. En ik ging maar half schertsend op zoek naar een foto van iets met een skelet aan de binnenkant en een huid aan de buitenkant, maar het Legoblok was waarschijnlijk het minst gruwelijke. Maar in veel opzichten is dit de manier waarop ik me een soort van voorstelling en mentaal beeld van de uitdaging waar we soms voor staan met analytische platforms en databases die hen ondersteunen. En dat is dat je eigenlijk alleen als consument en eindgebruiker of zelfs een ontwikkelaar vaak de laag van de fineerhuid ziet, maar het is eigenlijk het skelet eronder - het is echt het probleem waarop je je moet concentreren.
Weet je, in dit geval, wanneer we nadenken over de dingen die van invloed kunnen zijn op de databaseprestaties en -analyses die het gevolg zijn van die specifieke dag, de prestatiehits, de kerninfrastructuur en alleen het bewaken van die kerninfrastructuur, en zoals ik zojuist heb uiteengezet uw schijf en geheugen en CPU. En zoals Dr. Robin Bloor benadrukte, uitdagingen nu in virtualisatie en dingen die gebeuren in de chips zelf, en prestaties tot op kernniveau, en de hoeveelheid geheugen die nu in elke chip in elke kern wordt gestopt. Dit zijn zeer technische uitdagingen voor een alledaags persoon.
Op de hoogte blijven van query-monitoring. Weet je, een van de uitdagingen rond het bewaken van query's en querywachtrijen is bijvoorbeeld - ik bedoel, SQL als taal en de databasehulpmiddelen die beschikbaar zijn in analysetools, zijn zeer krachtig en vooral SQL als taal. Maar met die kracht en eenvoud komt ook, in veel gevallen, en dat is dat, als het geen applicatie is die steeds opnieuw hetzelfde doet, geschreven door een goede ontwikkelaar en gespot door een goede DBA, het misschien mensen zijn die ongestructureerde vragen stellen.
En het probleem daarmee is dat het vrij eenvoudig is om een beetje SQL te leren en vragen te stellen, maar als gevolg daarvan heb je niet noodzakelijk alle vaardigheden en ervaring en kennis om te weten of je een goed of slecht ding om de database te doen. Dus voortdurend hetzelfde grote, brede, verkeerde uitvoeren, kan het gebouw gewoon naar beneden halen. Het bijhouden van query-monitoring is een interessante uitdaging.
Volg alleen de responstijden voor wat het platform doet en wat gebruikers krijgen. Nogmaals, weet je, zonder de juiste tools is dit niet iets dat je intuïtief bekijkt en denkt: "Oh, het netwerk is traag", "Gebruikersgeheugen presteert niet goed" of "Indexen presteren slecht "Of" zijn opgeblazen. "
En dan, weet u, hoe komt u op het punt dat u, zodra u er een probleem mee hebt gezien, het uit elkaar haalt en uit elkaar haalt en de hele uitdaging van slecht gestructureerde vragen aanpakt? En, weet je, is het een ad-hocquery die iemand met de hand uitvoert, of is het een analysetool met een dashboardfront-end die slecht presteert omdat ze de vragen op de verkeerde manier stellen, of is het gewoon een echt, echt slecht geschreven stuk code?
En dan dat iteratief te doen, zei Eric in de opzet aanvankelijk, weet je, gewoon iteratief steeds maar opnieuw gaan en die workflows bijstellen. Weet je, welke workflows voer ik uit, hoe draaien ze, hoe vaak lopen ze, welke code loopt er tegen, waar lopen ze tegen in CPU en geheugen en schijf en netwerk? Ja, dat is gewoon een heel, heel technische uitdaging.
En dan het nirvana waar mensen naar op zoek zijn in deze wereld, terwijl het verschuift van historische analyse en het afstemmen van prestaties en het waarschuwen tegen je omgeving, wat geweldig is om te zien omdat je er in de toekomst misschien een plan voor krijgt als je weet waarom de dingen traag gingen gistermorgen om negen uur. Maar dat helpt je nu niet, en het helpt je plan niet vooruit.
Ik denk dat capaciteitsplanning en -groottes en -schaling en -afstemming, dus weet je, ik denk dat er een trend is die we nu zien, waarbij er een verschuiving is in zeer grote omgevingen waar mensen grote databaseplatforms hebben en breed verspreide databaseomgevingen te gaan van historische alarmering en planning tot voorspellende alarmering en planning, waarbij ze willen weten wat er op dit moment gebeurt en in de toekomst kunnen plannen. Of hebben we onvoldoende geheugen en hebben we het komende uur geen geheugen meer, en wat kunnen we eraan doen? Welke capaciteitsplanning kunnen we in realtime doen?
Pardon. Het komt op het punt dat, weet u, alleen de hele uitdaging van het ontdekken van deze hindernissen in de weg staat van in essentie wat wij vloeibare analyse noemen, en dat de norm in uw organisatie maken. Zoals je kunt zien, is het een niet-triviale uitdaging voor, weet je, alleen de dagelijkse grote, ongewassen massa's. En het is nog steeds een niet-triviale uitdaging voor zelfs de meer technisch onderlegde.
Weet je, als het moeilijk is voor stervelingen, hoe kunnen we dit dan mogelijk maken? Omdat, weet je, de meeste van deze dingen zijn die gewone gebruikers niet kunnen oplossen, en we hebben misschien een aantal speciale database-ingenieurs, database-ontwikkelaars, code-ontwikkelaars, programmeurs, maar ze moeten echt de omgeving kunnen ontbundelen. Ze moeten dingen uit elkaar halen, zoals mensen die code hergebruiken.
Weet je, een van de ergste dingen die ik heb gezien in deze ruimte rond prestatiehits in analyseplatforms in zeer grote implementaties van databaseserverinfrastructuur, is dat mensen een stuk code, een stuk SQL of een gestolen procedure nemen die ze niet hebben gedaan ' t schrijven, en ze weten niet of het een goed of slecht stuk code is, en ze hergebruiken het gewoon omdat het hen het gewenste resultaat geeft. Maar het bleek dat het gewoon iets was dat direct werd geschreven om een of twee resultaten te krijgen, zoals een rapport - iemand had haast.
En dus gebruiken mensen complexe code die ze niet hebben geschreven, en gooien ze het gewoon in een stukje applicatie-ontwikkeling, niet wetende dat ze eigenlijk de back-end straffen. Alleen al het monitoren van die prestaties en kijken naar waar de vragen vandaan komen en naar beneden boren, dat, weet je, dat is een dagelijkse uitdaging die ik zie.
Fundamentele gedragsmatige dingen zoals pre-enscenering van gegevens voor prestaties waar mogelijk. Dingen die je alleen ervaart, leren je alleen, zoals het verwijderen van indexen als je bulkimport gaat doen en vervolgens opnieuw indexeren, zodat de indexen niet worden onderhouden wanneer je terabytes aan gegevens verzamelt. Weet je, zonder het juiste gereedschap, is dat bijna niet te zien omdat je niet weet dat de index gehamerd raakt.
Het regelmatig optimaliseren van indexen is een soort van 101, maar hoe zit het met, weet u, wanneer u bulkimport uitvoert of, weet u, een tabel met zoekopdrachten maakt als iemand een echt grote zoekopdracht uitvoert? Weet je, dat kan een enorme prestatiehit zijn, en nogmaals, als je niet controleert, heb je niet de tools om dat te zien, dat gebeurt gewoon op de achtergrond en je weet niet hoe je het moet aanpakken .
Query's beperken tot alleen het aantal kolommen dat u nodig hebt - ik bedoel, het klinkt heel eenvoudig, maar nogmaals, als u het niet kunt zien, weet u niet dat het gebeurt, en dan gebeurt het gewoon op de achtergrond en doet het u pijn, bij u.
Weten wanneer en waar tijdelijke tabellen moeten worden gebruikt, grote verwijderingen en updates verzamelen. Nogmaals, allemaal heel eenvoudige dingen, maar zonder die zichtbaarheid, zonder de tools om dat te doen, zitten ze gewoon op de achtergrond en blijven je pijn doen en blijf je gewoon meer geheugen of CPU naar een databaseomgeving gooien voor betere prestaties van het analyseplatform, wanneer eigenlijk zou je in staat moeten zijn om in detail in te gaan op wat je pijn doet en dat specifieke ding aanpakken. En dan, weet u, dingen als beperkingen van buitenlandse sleutels en hoe vindt u dat, hoe weet u zelfs dat dat een probleem is?
Dat brengt mij tot de conclusie van mijn kernpunt hier, en dat is dat, weet u, we dagelijks deze problemen overal tegenkomen. En naarmate databaseomgevingen groter en groter en meer en breder worden, en zoals Dr. Robin Bloor hier benadrukte, krijgen we steeds meer complexe milieumodellen met databasetijden.
En dan ook de noodzaak om te integreren in enkele van de big data-platforms zoals Hadoop en Spark die op komst zijn, en meer en meer tegelijkertijd. Het past ons, naar mijn mening, om betere manieren en specifieke tools te vinden om deze real-time platformprestaties en analyses en diagnostiek intelligent uit te voeren. Omdat het real-time en echt geld en frustratie voor eindgebruikers en echte dollars kost als we niet beginnen met de tools om in deze dingen te duiken.
En daarmee ga ik het overhandigen aan onze vrienden van IDERA, omdat ik geloof dat ze een goed verhaal hebben om te vertellen hoe we dit probleem kunnen aanpakken.
Bullett Manale: Klinkt goed. Heel erg bedankt, en ik zal doorgaan en dingen aftrappen. Ik heb hier ook een paar dia's, en laat me doorgaan en dat soort naar voren brengen. Sommige hiervan gaan we vrij snel door.
Om je wat inzicht te geven, ben ik de directeur van sales engineering hier bij IDERA, en dus praten we vrij regelmatig met DBA's over de pijn en de uitdagingen die ze hebben, specifiek voor, in veel gevallen, prestatiebewaking en dat soort dingen, uiteraard. En we horen veel van dat publiek, en dus denk ik dat ik een deel van de informatie die ik van hen ontvang op een regelmatige basis kan delen die logisch zal zijn. Ik ga er een paar doornemen, want ik denk niet dat ze echt relevant zijn voor het gesprek.
Weet je, ik heb hier mijn eigen lijst met de verantwoordelijkheden van de DBA - het lijkt veel op de lijst van Robin en ik denk dat het redelijk consistent is. Ik denk dat wanneer je met een databasebeheerder praat, het altijd is - weet je, ze zijn opgesomd in sommige van deze gebieden meer dan andere en er is geen rijm of reden daarvoor, het hangt gewoon van de omgeving af.
Je hoort een behoorlijk breder, breed scala aan dingen die mensen willen kunnen doen. En vaak doen de mensen die deze dingen willen niet - ze vragen erom en in sommige gevallen begin je een beetje te boren in wat ze echt vragen, en dan kom je erachter dat ze ' ben echt op zoek naar meer. Ze willen echt meer informatie dan wat ze in eerste instantie denken dat ze nodig hebben, en als je in de tool begint te boren, denk ik dat je daar kunt beginnen te zeggen dat ze een gesprek met de gegevens hebben.
En ik denk dat dat een heel interessante zin is, en het is heel logisch om te kunnen zeggen, ja, nou, als je een slechte vraag hebt, wat is dan echt een slechte vraag? Is het een query die veel leest of schrijft of CPU verbruikt? Het kan er een zijn die veel loopt, het zou er een kunnen zijn, weet je, dat is, zoals je zei, slecht geschreven.
In termen van hoe we dat identificeren, zijn er een aantal manieren die u zult zien in termen van ons product, het Diagnostic Manager-product, dat we de DBA's laten zien dat ze dat kunnen aanpakken. En het is echt flexibel, en ik denk dat dat een van de grote dingen is - je moet een hulpmiddel hebben dat je gaat helpen met deze prestatieproblemen, de omgeving van iedereen is een beetje anders.
En er zullen veel, weet je, behoeften en misschien zelfs obscure eisen zijn op het gebied van monitoring, dus je moet iets hebben dat flexibel is en iets dat gaat werken en in staat zijn om te voldoen aan de omgeving die je probeert te beheren. Weet je, en ik heb veel van deze voorbeelden - ik ga ze niet allemaal doornemen, maar je hebt iets nodig dat je heen en weer kunt draaien tussen het ene stuk gegevens en het andere, en ik zal praat daarover als we een beetje in het product stappen en laten je dat zien, en in termen van hoe we het doen.
Maar het andere ding dat ik denk met betrekking tot een goede analyse-tool is, weet je, er zijn enkele kerndingen waar je echt naar op zoek bent. U wilt natuurlijk in de eerste plaats geen tool die zijn eigen prestatieproblemen zal veroorzaken in de naam van de uitvoering. Als ik zeg: verzamel de gegevens zonder kosten, dan heb ik het niet over de kosten in termen van, u weet wel, monetaire kosten, maar in termen van de kosten in termen van overhead en de kosten in termen van de hoeveelheid middelen die we gaan gebruiken in naam van de uitvoering. Je wilt daar zeker iets dat gaat helpen.
Je hebt iets nodig dat in staat is om de gegevens te krijgen waarnaar je op zoek bent, specifiek voor de problemen waar je dagelijks mee te maken hebt, en er zijn misschien dingen die je niet nodig hebt en die je niet ' t willen, en het heeft geen zin om die gegevens te verzamelen als je er nooit over gaat rapporteren of er behoefte aan hebt om die gegevens te beheren. Bijvoorbeeld met betrekking tot de metagegevens die zijn gekoppeld aan prestaties.
Weet je, een goed voorbeeld is, ik hoef niet gewaarschuwd te worden als de Distributed Transaction Coordinator-service in SQL niet werkt als ik niet wil dat deze überhaupt wordt uitgevoerd. Dus waarschuw me niet, verzamel er geen gegevens tegen - ik heb die informatie niet nodig. Het is dus heel belangrijk om die dingen aan en uit te zetten.
De mogelijkheid om, als je eenmaal de gegevens hebt verzameld, er vrij snel toegang toe te hebben - je hoeft, je weet wel, de gegevens uit te voeren en te masseren, de gegevens te manipuleren - om het snel en efficiënt te kunnen doen. En als je eenmaal de gegevens hebt, is het natuurlijk erg belangrijk om deze te kunnen begrijpen.
Nu, dit is waar, met onze - met, zoals bijvoorbeeld het Diagnostic Manager-product dat ik je vandaag een beetje laat zien - dat product, weet je, ik zou je graag willen vertellen dat dat product vervang en word een DBA in een doos. De realiteit is dat het enige kennis vereist van wat uw omgeving is en wat u probeert te bereiken. Het is uiteraard belangrijk dat we wat inzicht hebben in de rol van de DBA zelf.
Wat we nu proberen te doen, is opvoeden door middel van hulp en andere methoden. Maar je zult dit natuurlijk altijd willen koppelen aan een bepaald ervaringsniveau of iemand die enige kennis heeft van wat hij moet doen zodra hij de gegevens heeft ontvangen. En het is duidelijk van cruciaal belang dat iemand een persoon heeft die de juiste vragen kan stellen aan een product en dat gesprek met de gegevens heeft. En dan duidelijk in staat zijn om de gegevens te begrijpen.
Als ik eenmaal over de informatie beschik, om dat bij de juiste mensen te krijgen. Mijn ontwikkelaars, mijn operatieteam - wie het ook is, ik moet misschien integreren met andere producten en de haakjes hebben om dat te kunnen doen. Dit zijn allemaal echt belangrijke dingen. En dan, uiteraard, last but not least, als ik meer moet weten, in staat zijn dat te doen. Of het nu gaat om het inschakelen van wat meer om verzameld te worden, of om het gewoon wat dieper ingaan op de gegevens. Je hoopt dat je, met een tool dat gaat worden, weet je, helpt met de prestaties, alle dingen krijgt die je nodig hebt om die vragen te kunnen beantwoorden.
Het enige dat ik hier niet heb gedaan en waarvan ik denk dat het waarschijnlijk het vermelden waard is, is dat je een hulpmiddel nodig hebt dat je helpt te onderscheiden wat normaal is en wat niet normaal is. En ik denk dat dat een grote is, want weet je, er zijn een heleboel waarschuwingsproducten en dingen die er zijn, maar als je een waarschuwing krijgt en de waarschuwing een valse waarschuwing is, is het niet goed voor je ; het is meer tijdverspilling en het zal uw efficiëntie meer verminderen dan dat het hen zal helpen. Dus, weet je, dat zijn enkele dingen die ik in gedachten zou houden.
Als ik het heb over het product dat ik al deze dingen aan het IDERA-productsuite koppel, is het het Diagnostic Manager-product dat volgens mij waarschijnlijk de belangrijkste kenmerken heeft in wat we hier praten in termen van database afstemming en prestaties en monitoring en dat soort dingen.
Mensen zijn op zoek naar monitoring op ondernemingsniveau; ze willen toegang hebben, in één scherm kunnen weten dat dingen werken zoals ze zouden moeten zijn. Of ze willen, uiteraard, als er een probleem is, kunnen zien waar het probleem is en er vervolgens in kunnen doordringen. Ik denk echt dat dit een groot deel is van wat mensen zoeken met dit soort manieren waarop je je prestaties echt kunt verbeteren.
Het andere ding dat duidelijk daarmee samengaat, is dat ik niet alleen in het heden kan opereren, en dat ik over perioden terug moet kunnen gaan, of dat betekent dat ik naar vragen kijk die slecht liepen of dat het betekent dat je weet, kijkend naar de manier waarop de host-VM zich in termen van middelen gedroeg. Al dat soort dingen die je moet kunnen doen, en je gaat daar niet 24 uur per dag, 7 dagen per week naar je console zitten staren.
Als je op vakantie bent of midden in de nacht, of wat het ook is, je hebt iets nodig dat terug in de tijd kan gaan om te kunnen zeggen wat er aan de hand was in de instantie op de tijd dat we een probleem hadden. En dat, opnieuw, efficiënt en snel kunnen doen en erin kunnen doordringen, is absoluut een belangrijk stuk in deze discussie. En ik zou zeggen dat het waarschijnlijk een van de belangrijkste dingen is in termen van wat mensen zoeken. Ze zijn altijd op zoek naar dat venster naar het verleden, want dat is echt een im - Weet je, je wilt daar niet blijven zitten en wachten tot er weer iets gebeurt.
Het volgende op de lijst is eigenlijk alleen maar teruggaan naar waar we eerder over spraken, met de zoekopdrachtprestaties zelf. En ik ga u een paar verschillende voorbeelden binnen het Diagnostic Manager-product laten zien, hoe we dat doen, wat u zeker aan het einde van de dag veel opties biedt rond de vragen zelf in termen van wat je wilt verzamelen.
In termen van of u geïnteresseerd bent in vragen die bronpijn, CPU-verbruik of I / O veroorzaken. Of het nu gaat om vragen die lang duren om te voltooien of vragen die in het algemeen misschien niet de ergste inbreuk zijn op het gebied van prestaties, maar die zo vaak kunnen worden uitgevoerd dat de pure frequentie van het zelf uitvoeren een probleem zou kunnen zijn. En uiteraard is het ook een belangrijk onderdeel om trends in de loop van de tijd met die vragen te kunnen herkennen.
Er zijn veel verschillende manieren waarop we dat binnen dit product kunnen doen, en ik denk dat dat voor de meeste DBA's natuurlijk een heel belangrijk stuk is. En zelfs als je geen eigen intern ontwikkelde applicaties hebt, is het nog steeds leuk om naar je softwareleveranciers te gaan en te zeggen: "Hé, weet je wat? Weet je, elke dag om twee uur 's middags wanneer deze taak van start gaat, ' of wat het ook is, 'het is jouw applicatie die dit veroorzaakt, en we moesten het laten repareren.' Dus zelfs als je niet compleet bent controle over de code zelf, het is nog steeds leuk om te weten wanneer er problemen optreden.
En dan, weet je, het andere deel is duidelijk proactiever. De eerste zijn die het weet, kunnen begrijpen wanneer er een probleem optreedt. Om niet alleen de eerste te zijn die het weet, zodat u het kunt corrigeren, maar in veel gevallen, wanneer u dat nodig hebt, is er iets dat in staat zal zijn om een reactie te automatiseren, in veel gevallen ook. Je kunt, zeg, weet je, in plaats van een e-mail te krijgen met de tekst: "Hé, je moet dit oplossen", als ik in een vergadering ben of als je, weet je, onderweg bent of wat ik ook ben ben het aan het doen, het is natuurlijk heel fijn om te kunnen zeggen dat ik iets op mijn plek heb staan dat dat op een geautomatiseerde manier kan aanpakken.
En als het niet op een geautomatiseerde manier wordt aangepakt, in ieder geval als eerste op de hoogte zijn, zodat u corrigerende maatregelen kunt nemen of contact kunt opnemen met iemand die dat kan. En dus zijn dat duidelijk grote belangrijke zaken voor, weet je, dit soort problemen die je zou kunnen tegenkomen in termen van de monitoring van je machines en je instanties en de analyses zelf.
Nu heb ik hier eerder over gesproken, wat de flexibiliteit van dingen is. Ik kan dit niet genoeg benadrukken, out of the box kunnen zeggen, weet je, als er iets is dat niet wordt gemonitord, in staat zijn om de functionaliteit binnen een product te hebben om die dingen toe te voegen aan worden gecontroleerd. En in de zin van het voorbeeld van Diagnostic Manager hebben we natuurlijk, weet u, WMI-tellers, tellers, SQL Server-tellers, u kunt uw eigen query's maken.
Je kunt zelfs, als je dat wilt, de gegevens uit je vCenter-omgeving of je Hyper-V-omgeving halen, als gevolg van de polling die plaatsvindt en in staat zijn om dat op regelmatige basis te doen en die gegevens ophalen en kunnen bekijken. En nogmaals, draai van de ene plaats naar de andere terwijl u deze informatie bekijkt.
Dus dat zijn het soort dingen die, in termen van wat ik mensen zie vragen wanneer ze het hebben over een tool die hen gaat helpen bij het afstemmen en prestaties - het product dat ik je ga laten zien in slechts een ten tweede is Diagnostic Manager, en het ondersteunt alles van 2000 tot en met 2016. Het is specifiek voor SQL Server en daarom monitoren we die dingen. Er zijn geen agenten op de instanties zelf die de instantie controleren.
Dat gaat terug naar het verzamelen van de informatie tegen een kleine vergoeding, dat, u weet, we hebben duidelijk geprobeerd meer informatie te verzamelen, niet veel bronnen gebruiken, toch? We proberen de dingen die SQL Server ons al biedt, te verbeteren en te verbeteren, of het nu gaat om dynamische managementoverzichten, of het uitgebreide evenementen zijn, of wat het geval ook is wat betreft de verzameling zelf. Het is een van onze mandaten om die informatie te benutten en te verbeteren.
Nu, als je hier heel snel doorheen kijkt, ga ik niet te gedetailleerd door de architectuur, maar heb ik een back-end repository met al onze historische gegevens die je kunt beheren en die je kunt bewaren zolang jij wil. U kunt zelfs het type informatie kiezen dat u wilt bewaren en voor hoe lang. Dat gaat een beetje terug, de juiste gegevens verzamelen en de onnodige gegevens weglaten. Als u de vijf dagen lang kernvragen wilt houden en uw meldingen vervolgens twee jaar wilt bewaren, is dat aan u en dat is volledig uw recht om dat te kunnen doen.
Een aantal verschillende consoles met dit product. Je hebt een webversie, je hebt ook een dikke clientversie. En dat is dus de flexibiliteit om in een browser te springen en te zien wat er aan de hand is, of als u een laptop hebt waarop een speciale client is geïnstalleerd, een van deze benaderingen zou voor u werken.
Wat ik graag zou willen doen is een soort snelle demonstratie doen. En ik wil erop wijzen - ik ga terug naar deze andere dia hier - die we hebben, we hebben zojuist toegevoegd, net als een FYI voor die mensen die bekend zijn met het product, we hebben een nieuw aanbod dat de Diagnostic Manager Pro. Een professioneel aanbod dat iets omvat dat we Workload Analysis noemen.
En het gaat echt over het in staat zijn om interactief naar zeer grote tijdsperioden te kijken en van dat, je weet wel, 30-dagen weergave naar de, je weet wel, vijf minuten weergave in ongeveer drie klikken te gaan. En als je de piek in prestaties of het probleem in de bottleneck kunt zien, weet je, zou je in staat zijn om op een zeer hoog niveau te zien en naar een zeer laag niveau te boren. En vooral dat ook vandaag, dat is nieuw voor het product.
Maar wat ik eigenlijk wil doen, is gewoon een soort van beginnen en ik wil een beetje praten over dat draaien en heen en weer gaan. En ik heb een voorbeeld naar voren gebracht en ik ga het hier op mijn scherm delen. En, laten we kijken … Daar gaan we. Mijn scherm En laat me weten, jongens, dat je het kunt zien.
Eric Kavanagh: Daar ga je.
Bullett Manale: Is alles goed daar? Alright. Dus waar je nu naar kijkt - en dit is het Diagnostic Manager-product - en ik wilde je gewoon een soort demonstratie op hoog niveau geven van wat hier aan de hand is. In dit specifieke voorbeeld laten we u de vragen zien die horen bij wachten. En dus als ik het heb over heen en weer kunnen gaan, dieper doordringen en draaien, dat is - dit beeld hier is daar een goed voorbeeld van. Ik kan vanuit een tijdlijnweergave gaan zoals we hier zien, die nu wordt weergegeven. In ons geval kijken we naar het wachten zelf en de categorieën van het wachten zelf. We kunnen de verklaringen zien die verband houden met die wachttijden, we kunnen de toepassingen zien.
Merk op dat het hier in een tijdlijnweergave staat, dus ik kan die informatie lineair identificeren op basis van wanneer het probleem zich voordeed, maar nogmaals, als ik gewoon, nogmaals, wil draaien, en ik zeg: "Weet je wat, laten we eens kijken naar dit vanuit een ander perspectief, "laten we doorgaan en dit bekijken vanuit het standpunt van:" Ik wil de vragen of het wachten of de toepassingen zien die me het meeste pijn doen, en ze rangschikken. "En dat is wat we ' opnieuw gaan zien door "query wacht op duur". Nu zien we de applicaties zelf die me de meeste pijn doen, of het wachten.
En dan, hier is het deel dat echt het belangrijkste deel is, deze dingen kunnen isoleren. Ik zie dat deze NoSQL-applicatie hier van start gaat. Het veroorzaakt me een goede hoeveelheid wachttijd, ver in de hoeveelheden van 25 seconden wachttijd binnen dit venster van 30 minuten waar we in zijn geboord. En ik kan die toepassing dan isoleren en ik kan de verklaringen zien, in dit geval, die direct van invloed zijn op dit specifieke geval.
En dus is dit slechts een voorbeeld van hoe u een knelpunt kunt identificeren, de informatie kunt rangschikken, de prioriteit kunt geven aan de problemen die eerst moeten worden aangepakt. Dit zijn allemaal dingen waarmee u rekening moet houden. Weet je, je kunt de hele dag problemen oplossen, maar als je de problemen aan het oplossen bent die onderaan de lijst staan, verspil je je tijd. U heeft hieraan alternatieve kosten.
Ik zal je nog een voorbeeld geven, en dit is een beetje een ander voorbeeld. In plaats van specifiek op een probleem te wijzen of op een gebied te wijzen, heb je ook een hulpmiddel nodig dat je in brede zin kan helpen, door te kunnen zeggen: "Hé, hebben we problemen gehad?" Of "Zijn er dingen die ik kan doen om de prestaties te verbeteren? ”en om iets achter de schermen te zien, kijken wat er aan de hand is. En in dit geval kan dit verband houden met de configuratie; het kan gerelateerd zijn aan de manier waarop de gezondheid van de instantie zelf wordt beheerd. En natuurlijk ook prestatiegerelateerde dingen.
Als ik hier naar deze knop Analyseren ga, wil ik je laten zien dat we binnen dit product ook een soort proactieve lijst hebben van dingen die kunnen worden uitgevoerd in een gerangschikt formaat dat je in wezen inzicht geeft in de dingen die u waarschijnlijk een toename van uw prestaties op die instantie geven, of een verbetering van de gezondheid van die instantie. En het is in een gerangschikt formaat in die zin dat je dat vermogen hebt om te zien welke waarschijnlijker zijn om je prestaties te verbeteren die specifiek zijn voor een bepaald type probleem dat is geïdentificeerd.
En dus, als ik naar deze dingen kijk en ze identificeer, zie ik niet alleen dat ik een probleem heb en heb ik in veel gevallen ook een script dat automatisch kan worden gebouwd om dat probleem op te lossen. Maar in veel van deze gevallen hebben we ook externe links die verwijzen naar het soort probleem dat we ondervinden, en waarom we deze aanbeveling ook geven, zodat u dat educatieve aspect van de dingen krijgt. Wat, nogmaals, ik denk dat het heel belangrijk is als je het hebt over het oplossen van problemen.
Ik wil deze aanbevelingen niet blindelings volgen, ik wil begrijpen waarom deze aanbevelingen worden gedaan. En ik ben misschien een senior DBA die dit al 30 jaar doet en ik heb iets nodig dat gaat, weet je, controleer de - of stip de i's en steek de t's over, in dit geval - of misschien ben ik een junior DBA en Ik heb een beetje hulp nodig bij het begrijpen van deze problemen terwijl ze zich voordoen en waarom deze aanbevelingen worden gedaan.
Zoals ik al zei, ik ga je gewoon door een paar verschillende delen van het product leiden. Deze tool bestaat al, weet je, hij bestaat al sinds 2004, 2003. En er zit echt veel ontwikkeling in, veel informatie, dus het zou geen zin hebben om je hier alles te laten zien. Maar ik denk dat een van de dingen die het vermelden waard is, is dat wanneer we naar binnen gaan en we beginnen te praten over alle dingen die je kunt controleren en alle dingen die je kunt waarschuwen, nogmaals, terug naar die flexibiliteit van dingen, hier is een lijst van alle items die we monitoren.
Het betekent niet noodzakelijkerwijs dat ik deze dingen als een waakzame staat wil beschouwen als ze uit de problemen raken wat betreft de drempel, dus je kunt deze dingen in- en uitschakelen. Dit gaat terug naar dat: "Hé, ik moet alleen bepaalde dingen doen met bepaalde statistieken. Ik hoef alleen maar, weet je, op bepaalde problemen te letten. 'En ervoor kunnen zorgen dat we je niet gaan verzadigen met een hoop valse positieven. U hebt niet alleen de mogelijkheid om deze dingen in en uit te schakelen, maar in veel gevallen zult u merken dat we ook die normaliteit bieden voor elke statistiek. Dus als ik naar dit specifieke, in dit geval een basislijn kijk, zou ik opmerken dat de drempel waarschijnlijk hoger is waar ze nu zijn.
Aan de andere kant van de medaille staat: wat als ik een exemplaar van SQL heb, waar ik enkele metrieken volg en die metrieken, om welke reden dan ook, zijn de drempels die ik heb ingesteld onjuist? Met andere woorden, de drempels zijn schar in het midden van waar de baseline daadwerkelijk staat, wat betekent dat als ik een waarschuwing heb die aan die drempel is gekoppeld, ik waarschijnlijk een waarschuwing krijg voor iets dat een normale gebeurtenis is. En dus kunnen we u in dat soort situaties ook over de hele linie dat inzicht bieden.
Voor alle statistieken over dit specifieke exemplaar, zie ik die drempels die waarschijnlijk waarschijnlijk een vals positief resultaat zullen vertonen in termen van wat normaal is en wat niet. Dit wordt iets dat als een normaal gebruik aan de geheugenzijde zou worden beschouwd, en als ik die drempel wilde verhogen, zou ik het kunnen, maar dat is een beetje het idee met de basislijnen.
En het leuke van het Diagnostic Manager-product met betrekking tot de basislijnen zelf, is de mogelijkheid om meerdere basislijnen in te stellen. En u kunt vragen: "Waarom zou ik dat willen doen?" En het antwoord is, nou ja, als u een onderhoudsvenster heeft dat loopt van, laten we zeggen, middernacht tot 4 uur 's ochtends, waar u echt uw middelen belast, u gebruik je de middelen echt zoveel mogelijk, dan wil je weer kunnen verschuiven en wil je een beetje draaien en zeggen: "Kijk, we gaan daarvoor onze drempels veranderen." En we kunnen onze drempels in het bijzonder dynamisch aanpassen aan de basislijn waarin we ons bevinden, op basis van het tijdstip van de dag of dag van de week enzovoort, dat is het. Dus het zal dan dynamisch die drempels voor ons aanpassen.
Laten we nog een stap zetten. Als we eenmaal die drempels hebben geïdentificeerd, als we eenmaal zijn doorgegaan, en, in termen van het instellen van waarschuwingen en meldingen en op de hoogte zijn van deze situaties die zich kunnen voordoen, is flexibiliteit hier weer van het grootste belang. U wilt in specifieke situaties kunnen waarschuwen. In andere situaties wilt u misschien een e-mail naar iemand anders sturen, wilt u misschien een PowerShell-script uitvoeren, misschien weet u dat de lijst doorloopt.
Ik wil misschien integreren met iets via SNMP-trap of zelfs rechtstreeks met bijvoorbeeld SCOM. Het punt is, je hebt de flexibiliteit om dat te doen, en je kunt alle soorten voorwaarden instellen die dat rechtvaardigen, of het nu gaat om een zeer brede situatie - weet je, mijn CPU en geheugen of welke bronnen dan ook - in al mijn instanties, of misschien heb ik een heel specifiek soort dingen waar ik op wil letten, omdat, wanneer ik ontdek dat we in overtreding zijn, ik een heel specifiek en gericht script voor dat probleem wil uitvoeren. Dus dit is waar u dat soort dingen in het Diagnostic Manager-product zou kunnen doen, gewoon, weet u, in termen van de waarschuwing en de kennisgeving, en in staat zijn om flexibel te zijn vanuit dat oogpunt.
Nu zal ik niet door al die waarschuwingen en al dat goede spul gaan. Ik wilde wel over de rapporten praten. En nogmaals, in staat zijn om de informatie op een aantal verschillende manieren te gebruiken en te benutten - en dit gaat opnieuw terug naar het gesprek met uw gegevens. En veel mensen, wanneer ze dit product voor het eerst zien, denken ze: "Oh, nou, ik ga een tool hebben die me waarschuwt als er problemen zijn." Dat is wat ik nodig heb. ”En de realiteit is dat ze dat hulpmiddel nodig hebben, maar de andere kant is, als ze echt - ze hebben ook een hulpmiddel nodig om hen te helpen beslissingen te nemen, en ze kunnen deze informatie gebruiken die we hebben verzamelen in naam van de uitvoering en ook in naam van alarmering, om u te helpen beslissingen te nemen op de weg vooruit.
Weet je, een goed voorbeeld zijn mijn groeivoorspellingen in mijn database. Als ik een specifieke database heb die groeit, kan ik naar die database verwijzen of zelfs meerdere databases om te kunnen zien wat de groeisnelheden zijn. We laten je niet zien op basis van wat, weet je, wat het vandaag is; het gaat het voorspellen op basis van de groei in het verleden die we hebben meegemaakt.
Als ik hier een paar databases heb - die ik toevallig heb, stel je dat voor - zou ik kunnen ingaan en zeggen: "Laten we de laatste gegevens nemen, weet je, de jaarwaarde van gegevens, laten we dat per maand correleren, en in een steekproef aantal maanden, laten we doorgaan en kijken hoeveel groei we de komende drie jaar gaan zien, of 36 eenheden. ”In dat geval kunnen we die vraag heel snel beantwoorden. Probeer dat nu zelf te doen, toch? Probeer dat net zo lang te doen als ik het zelf heb gedaan. Het gaat een tijdje duren.
Laten we, om nog een beetje meer te benadrukken, nog een rapport nemen, wat mijn topserversrapport is. Stel je voor dat ik honderd productie-exemplaren heb, wat ik in dit geval niet heb. Maar als iemand naar mij toekomt en zegt: "Ik wil dat je me dat vertelt - we gaan deze nieuwe database voor deze geweldige nieuwe toepassing maken; het gaat alles veranderen zoals we het kennen; het gaat het leven zo geweldig maken. Oh, trouwens, de database zelf zal echt I / O-intensief zijn, of het gaat CPU-intensief zijn, of echt geheugenintensief …, "wat voor invulling het ook is, ik wil van al mijn productie-instances te kunnen zien, waar heeft het zin om die database te plaatsen? En ik kan al mijn instanties tegen elkaar rangschikken in termen van het contingente type, of het nu CPU, geheugen, schijf of wat het geval ook is. Het punt hier is dus om die vraag snel en efficiënt te kunnen beantwoorden en de juiste beslissing te nemen in plaats van te raden wanneer je het doet - die zijn allemaal duidelijk heel belangrijk en je hebt iets nodig dat je gaat helpen.
En als we het hebben over analyse, kan dit variëren van iets zoals waar we het over hebben met capaciteitsplanning tot de, je weet wel, waarschuwingen die je dagelijks tegenkomt die mogelijk met CPU te maken hebben, zoals en natuurlijk ook de vragen zelf, of er blokkering is, enzovoort.
Een ander voorbeeld hiervan zou zijn, als ik hier naar de administratie zou gaan - eigenlijk neem ik dat terug, de waarschuwende sectie hier - en vraag de bewaarplaats van onze historische informatie naar dingen die in het verleden zijn gebeurd. Heb ik blokkering gehad die zich heeft voorgedaan in mijn productieomgeving? Ik weet het niet, laten we het uitzoeken.
Ik kan teruggaan naar mijn productietag en ik kan zeggen, voor al mijn productie-instances, ongeacht de tijdsperiode, voor elke statistiek die ik wil identificeren. Als ik in een waarschuwingsstatus ben gegaan, in ons geval, laten we zeggen blokkeren door tellen, niet door seconden blokkeren, en ik kan teruggaan en, in dit geval, een paar maanden, als ik moet - of in dit geval, een maand - en ik zie dat blokkeren. Ik kan zien wanneer het begon, ik kan zien wanneer het eindigde, en ik kan inzoomen op elk van deze trekintervallen als ik moet, om de details van het blokkerende incident op zichzelf te zien. Je moet in staat zijn om iets te hebben dat heel snel is, in staat zijn om te vinden wat je nodig hebt en zoeken in plaats van veel cycli te draaien om het te doen. En dus dat denk ik dat ook belangrijk is.
Het laatste wat ik u graag wil laten zien - en u dit product, het Diagnostic Manager-product - laat zien, is dat we, zoals ik al eerder heb gezegd, zijn binnengegaan en een ander onderdeel hebben toegevoegd aan onze SQL Diagnostic Manager Pro aanbieden. En dat is het onderdeel Workload Analysis. En dit is een webversie van dit, in dit geval dat we u hier laten zien. Maar het punt hier is dat je hiermee een heel brede periode of een heel specifiek tijdvenster kunt bekijken, en van, weet je, een paar klikken om de code te zien die direct verband houdt met problemen die mogelijk zijn gebeurd .
Als een voorbeeld daarvan, als ik naar een weergave van vier weken kijk, zie ik hier, hier, alle pieken in termen van de databases en de prestaties van die databases en waar we wachtactiviteit op die databases zagen. Nu, en je kunt zien, als ik hier een piek zie, het voordeel van deze tool zelf is gewoon dat kleine balkje daar te kunnen markeren. En dan, als ik dat doe, verandert alle dingen hier. We zouden de databases kunnen zien, we zouden alle commando's kunnen zien die verband houden met wat er achter die balk staat.
Hetzelfde als ik zei: "Laten we de laatste vier uur bekijken" in plaats van de laatste vier weken. Dat kan ik nog steeds doen. Ik kan die periode nog steeds benadrukken, en dan vanaf hier - hier zijn nogmaals mijn draaipunten - al deze dingen waar ik naar toe kan linken. De bovenste SQL-instructies, ik zie die vragen, in dit geval, die wachttijden veroorzaakten die verband hielden met CPU-gebruik. Alleen al door in te boren, zie ik die vragen die hier aan de orde zijn - whoops - en ik kan ook de programma's zien en wat hier ook niet bij hoort.
Je krijgt hier veel inzicht, en niet alleen dat, maar je kunt zien dat het je dingen gaat vertellen als je naar het opdrachtniveau gaat. Het zal je vertellen of het zware operators ziet, je kunt dan de uitvoeringsplannen bekijken. Dit kost een beetje tijd omdat het behoorlijk uitgebreid is om deze te laden. Maar het punt hier is dat je veel verschillende manieren hebt om de gegevens te bekijken, om te zien waar je naar op zoek bent, en dan uiteraard in staat bent om actie te ondernemen daar waar je moet, dus, en deze neemt langer dan normaal, dus laat ik het daarbij.
En dus met dat gezegd, ik ga het teruggeven. En hopelijk was dit een goede demonstratie van het soort dingen waar we het over hadden. En zoals ik al zei, het product zelf dat we gebruikten om deze voorbeelden min of meer te geven, bestaat al heel lang, en dus veel andere dingen waar we over kunnen praten en laten zien, maar als dit iets is dat interessant is van jullie, kun je altijd naar onze website gaan en deze downloaden en ermee spelen.
Eric Kavanagh: En ik vind het geweldig dat je al dit detail toont. Als je een paar schermen teruggaat - zelfs dit scherm is behoorlijk goed. Omdat er zoveel verschillende manieren zijn om te visualiseren wat er feitelijk gebeurt, en ik denk dat dit tegenwoordig een van de meer ondergewaardeerde aspecten van computergebruik is. Het is zeker een databaseomgeving waar ik op veel manieren een grapje over heb die ik zeg: "We leren nog steeds om silicium te spreken." We leren nog steeds hoe we kunnen zien wat er gebeurt, en tot op welk punt was erg goed, je moet dat gesprek met gegevens hebben om beter te begrijpen wat er aan de hand is, waarom dingen langzaam gaan, omdat er zoveel mogelijke problemen zijn. En natuurlijk heeft IDERA een aantal verschillende producten, waaronder de oude Precise-producten waarvan ik denk dat ze hier een aanvulling op kunnen zijn.
Maar misschien Robin, ik zal het aan je overgeven voor een paar vragen, en dan Dez, een paar vragen van jou, en dan misschien iemand uit het publiek, wees niet verlegen. Stuur ze nu in.
Bullett Manale: Robin, ben je op mute?
Robin Bloor: Ja. Het is goed, ik zet mezelf gewoon stil. Ik moet zeggen, het is ongelooflijk - het ding dat me eigenlijk het meest dramatisch vond aan deze tool, omdat het echt - vooral gezien het feit dat het vrij duidelijk is dat een hele reeks dimensies waar je gewoon niet op inging - het ding dat eigenlijk, Ik denk dat dit het meest indrukwekkend is, het moet echt een heel goede manier zijn om een DBA te trainen. Weet je, het is - dus als je voor het eerst begint met databasewerk en je eigenlijk niet veel weet over wat er feitelijk in een database gebeurt, is het eigenlijk heel, heel moeilijk om inzicht te krijgen. Dus wordt dit veel gebruikt, specifiek voor training? Ik zou het gebruiken.
Bullett Manale: Ja. Ik bedoel, als je training zegt, bedoel je een soort van training in uitvoering als een soort DBA, toch? Wat betreft…
Robin Bloor: Ja, ja, ja, ja. Een leermiddel. Weet je, een.
Bullett Manale: Ja, ik denk zeker dat dat het geval is, en zelfs nog meer dat we dit hebben toegevoegd, de Analyse-component die we eerder aan u lieten zien, die alle aanbevelingen bevat die eraan verbonden zijn. Maar ik denk zeker dat je, binnen de hulp en veel verschillende gebieden binnen het product, je wel veel inzicht geeft. Veel informatie.
En de realiteit is, zoals ik al zei, je kunt dit gebruiken als je geen DBA bent. Je zult waarschijnlijk merken dat je een aantal Google-zoekopdrachten en dat soort dingen doet, gewoon voor de algemene kennis van wat de meeste DBA's hebben, maar je kunt dit correleren en het zal je zeker helpen in termen van: "Hé, weet je, hey wat dit ding dat fragmentatie wordt genoemd? 'of:' Waarom wordt deze zoekopdracht 6000 keer uitgevoerd? 'Ik bedoel, omdat deze dingen naar je toe worden gebracht en ze zullen opborrelen en je zult ze zien. Je zult zien dat je weet wat normaal is en wat niet. Je zult de dingen zien die piekeren en de dingen die dat niet zijn.
In de regel proberen we dit op te zetten als het gaat om best practices. Zodat, wanneer u het naar een instantie verwijst, het u de dingen zal laten zien die zijn geïdentificeerd als buiten de best practices. Ik bedoel, natuurlijk, weet je, de realiteit is dat best practices best practices zijn en het zijn niet altijd echte practices. Maar weet je, het zal je de uitbijters laten zien, zelfs vanaf het eerste punt dat je het installeert en naar een instantie verwijst.
En vanaf daar kun je een beetje verder gaan, omdat je noodzakelijkerwijs de problemen moet oplossen en moet vaststellen of dat echt een probleem is of iets dat normaal gebeurt van dag tot dag. En dan, omdat je veel informatie hebt om te helpen en de aanbevelingen, ja, absoluut.
Robin Bloor: Oké. En een andere vraag - maar ik weet zeker dat het antwoord hierop erg snel is - is dat je de granulariteit hebt om rechtstreeks naar de individuele vraag en het individuele tijdstip te gaan en vanuit die dimensie te kijken, .
Bullett Manale: Natuurlijk, ja. Afhankelijk van wat u wilt doen, kunt u kijken naar een tijdvenster van één minuut of u kunt kijken naar een tijdvenster van drie dagen of, u weet, een tijdvenster van drie weken. En weet je, zoals ik al zei, het hangt af van hoe je naar de gegevens wilt kijken, en ook wat je wilt verzamelen. In sommige gevallen verzamelen we alleen de zoekopdrachten die een door u geïdentificeerde drempel bereiken. In andere gevallen kunnen we elke zoekopdracht verzamelen die een wachttijd veroorzaakt.
Maar je hebt ook de mogelijkheid om te zeggen: "Kijk, die drempels die ik heb geïdentificeerd, misschien is het alleen voor schrijven, of misschien is het alleen voor lezen, of misschien is het alleen voor CPU." Dus, ervan uitgaande dat het die drempel heeft overschreden, dan is dat waar je over wilt verzamelen. In welk tijdsbestek je ook wilt kijken, je zou die vragen kunnen zien die aanstootgevend zijn, gebaseerd op wat je als aanstootgevend beschouwt.
Je hebt veel verschillende manieren om naar de gegevens te kijken. Je kunt er in geconsolideerde weergave naar kijken, je weet wel, de vragen die - hoeveel achter de schermen gestarte vragen, versus, weet je, elk incident van die beginnende vraag, om een patroon te bekijken, als je zal, om te zien of het voortdurend erger wordt.
Maar om uw vraag te beantwoorden, kunt u zeker wijzen op elk gewenst tijdstip. Je hebt dit ding dat de geschiedenisbrowser wordt genoemd - en ik gebruikte het een beetje - maar eigenlijk kun je op elk tijdstip in de kalender die je selecteert, direct naar dat tijdstip gaan.
Op dit moment kijk ik in 15 november om 19:05 uur, en we kunnen naar vragen kijken die specifiek zijn voor die tijd. Als ik er een had die slecht liep gezien dat tijdvenster, zouden we in staat zijn om de sessiedetails te bekijken die specifiek zijn voor dat tijdvenster om te zien welke sessies actief waren. Ik bedoel, er is een hele hoop gegevens hier, en zoals ik al zei, het moeilijkste deel is eigenlijk de misschien 30 minuten spelen met de console en uitzoeken hoe dit te doen.
Maar als u eenmaal beseft dat de meeste gegevens hier in dit lint staan en door deze tabbladen worden gedeeld, en elk tabblad zijn eigen set dynamisch veranderende knoppen heeft die verschijnen telkens wanneer u erop klikt, of u nu kijkt naar real- tijd dingen of dingen die vorige week gebeurden, het is hetzelfde proces. Eigenlijk kijk ik nu op 15 november, maar ik kan net zo gemakkelijk in realtime kijken door op die knop te klikken. En ik ga op dezelfde manier met de gegevens omgaan.
Maar om uw vraag te beantwoorden, ja, er zijn veel verschillende manieren om historische informatie te bekijken, en dat heeft ook betrekking op de vragen zelf.
Robin Bloor: Ik snap het. Het is heel indrukwekkend. En ik ben dol op het feit dat de vensters worden gesynchroniseerd, ook al is dat min of meer noodzakelijk geworden in alles wat tegenwoordig met realtime gegevens te maken heeft.
Bullett Manale: Ja. Zeker.
Robin Bloor: Hier is slechts een punt van informatie waarop ik eigenlijk het antwoord niet weet. Als uw aanbiedingen - SQL Server en de cloud - kunt u naar de cloud verwijzen onder Ratio?
Bullett Manale: Dat kan. Je kunt dit onder de cloud richten. Wanneer u daadwerkelijk instanties toevoegt, wordt u gevraagd of het RDS of Azure is. Nu zullen er enkele beperkingen zijn gebaseerd op wat ons vanuit de cloud wordt blootgesteld, dus er kan een zijn - er is een klein verschil in wat we kunnen controleren, simpelweg omdat de instrumentatie, in sommige gevallen, niet is er niet voor ons om te verzamelen op basis van wat Microsoft blootstelt.
Nu, als het zoiets is, weet je, infrastructuur als een platform, zoals, je weet wel, of EC2 of iets dergelijks, dat is helemaal geen probleem. We krijgen alles. En terwijl we werken met Microsoft en we werken met Amazon; we werken eraan om die informatie in meer detail bloot te leggen. Maar absoluut ja, we ondersteunen die omgevingen.
Robin Bloor: Oké, dat is interessant. Nou, ik zal Dez doorgeven, waarvan ik zeker ben dat ik je vragen uit een andere richting zal gooien.
Bullett Manale: Oké.
Dez Blanchfield: Bedankt. Ik heb twee hele snelle voor je. Ik denk dat, weet je, de eerste is, de schalen, weet je, ik denk dat een van de dingen die me opvalt is dat het algemene thema van de voorstelling iets is waar we aan denken als we heel groot, heel groot worden, zeer grootschalig en breed, en terabytes aan gegevens. Kijkend naar de demo, viel het me op, dit is iets dat zelfs van toepassing is op zelfs de zeer kleine omgevingen, een soort van alleen maar prestatiehits.
Wat voor soort verspreiding zie je in de opname hiervan, en denk je dat het, weet je, denk je dat het een hulpmiddel is dat een goed heeft, weet je - in mijn gedachten wel, dus ik denk dat het een ja is - maar ik ben gewoon benieuwd wat je ziet. Kleinere organisaties voeren dezelfde gesprekken en zijn op zoek naar een tool om dit te doen, of is het echt iets aan de grotere kant van de stad?
Bullett Manale: Het is grappig - dat is een goede vraag. Het is een beetje een mix, maar ik zou zeggen dat we heel veel kleine klanten hebben. En als ik kleine klanten zeg, bedoel ik, weet je, een tot vijf exemplaren aankopen om een licentie te beheren. Nu hebben ze in sommige gevallen misschien wel 30 exemplaren van SQL, en ze geven alleen echt om de vijf, echt, heel belangrijk genoeg om te investeren in een tool als deze, voor die vijf exemplaren.
Maar de realiteit is dat zelfs de kleinere winkels een handvol SQL-servers hebben. In de meeste gevallen, of in veel gevallen, is die kleine winkel erg, erg afhankelijk van die databases, omdat je weet wat ze doen. En dus doen ze het niet, ze kunnen het niet laten zakken. Ze kunnen niet, weet je, ze moeten een hulpmiddel hebben.
De keerzijde van die medaille is dat ze in sommige van die kleinere winkels geen speciale DBA's hebben, dus de man die de slimste man in de kamer is of de meer technische man in de kamer is uiteindelijk de toegewezen DBA. En dus zijn ze in die situatie zeker op zoek naar wat hulp, en deze tool zal hen uiteraard ook in dat opzicht helpen.
Voor je grotere omgevingen, omdat ik denk dat het Dez was die het noemde - of Robin, ik weet het niet zeker - maar, weet je, de grotere omgevingen, je zou verbaasd zijn hoeveel DBA's ze hebben, ik bedoel, we ' We hebben het over enorme aantallen exemplaren van SQL, en je hebt letterlijk een handvol DBA's die de taak hebben om ervoor verantwoordelijk te zijn. En vanuit dat perspectief, die jongens, weet je, zijn ze op zoek naar wat hulp omdat ze de middelen niet echt voldoende hebben om ze echt te helpen, en dus zal een tool dat deels compenseren.
En dus zien we dat ook best, waar, weet je, je hebt drie mannen die 200 instanties beheren. En dus kunt u zich de logistiek ervan voorstellen als u niet zo'n tool hebt, om te proberen uit te vinden wanneer er zelfs een probleem is. Het gaat geen proactieve manier zijn, ik kan je verzekeren. Dus hopelijk beantwoordt dat uw vraag. Ja.
Dez Blanchfield: Dat doet het, ja. Het viel me wel op - en ik denk dat Robin er een beetje op heeft gezinspeeld - maar, weet je, het soort belofte dat je beschrijft toen je de demo deed, ik bedoel, ze zijn niet exclusief voor zeer grote omgevingen. Weet je, je kunt een standaard kant-en-klaar platform kopen dat voor één ding is ontworpen en het in een gedeelde databaseomgeving voor iets anders plaatsen, en het straft gewoon de hele omgeving.
Het andere dat me opviel - het is niet zozeer een vraag, maar slechts een observatie, maar ik zal het wel tot een vraag leiden - en dat is dat, weet je, wanneer organisaties al hebben geïnvesteerd in hun infrastructuur en hun platform en hun database en de servers en de infrastructuur daaromheen, en ze gaan een product kopen, wat het ook is - een HR, een ERP, een BI-tool - ze hebben al een vrij grote investering gedaan.
Wat voor soort reactie zie je wanneer je een gesprek hebt met mensen en ze zich realiseren dat ze een prestatieprobleem hebben, maar ze voelen nu dat ze nog een investering moeten doen om erbij te komen? Is er een punt waarop ze zich realiseren als je het eenmaal ontdekt hebt dat ze dit ding als een no-brainer gebruiken, en het is niet zozeer een verkooppraatje, maar het is meer een epiphany. Het is gewoon, weet je, "We zullen hier onmiddellijk profijt van zien." In tegenstelling tot alleen het product moeten verkopen? Het lijkt mij dat het zichzelf verkoopt en de ROI springt gewoon van de pagina af.
Bullett Manale: Ja, en dat is grappig, je zegt dat omdat, wat heel vaak zal gebeuren, is dat iemand zal komen, zoals een DBA of zelfs de verkopers, en ze zullen zeggen: "Hé, deze jongens willen zie een, zoals, een ROI-blad hierover. ”En meer als een, iets op papier dat we naar hen zouden sturen. En de demo is altijd 10 keer beter, vooral omdat je het kunt doen met de DBA's zelf, omdat -
Dez Blanchfield: Ja.
Bullett Manale: Zoals u al zei, verkoopt het product zichzelf. Het is echt moeilijk om een ROI op een stuk papier te zetten en te zeggen: "Oké, hoeveel klikken klikt een DBA doorgaans, weet u, binnen een uur?" Voor back-ups, weet u, of wat dan ook, je weet wel? En als je dat op een stuk papier probeert te zetten, is het echt moeilijk om dat te doen. Maar wanneer u iemand krijgt en u het product laat zien, en zij zien het, is het precies wat u zei.
Mensen realiseren zich de waarde ervan. Omdat het niet alleen hen helpt beter te begrijpen en betere beslissingen te nemen, maar het helpt ook, weet je, dat ze niet de slechterik zijn. Zij kunnen de eersten zijn die het weten; ze kunnen het probleem oplossen voordat het ooit is vastgesteld dat er een probleem was.
Het andere deel daarvan is dat, weet je, als een DBA, of het een, weet je, echt of perceptie is - en ik denk dat het perceptie is - je echt de prestatieproblemen hebt. Jij bent de man die met je vinger naar je wijst wanneer de uitvoering naar beneden gaat, en de realiteit is dat het de ontwikkelaar kan zijn die het probleem echt veroorzaakt.
Ik heb een tool om te kunnen zeggen: "Hé, dit is niet mijn probleem, ik moet dit kunnen meenemen naar de ontwikkelaar en zij moeten dit corrigeren, " of, weet je, in die zin. Het is een leuke manier om iets in je arsenaal te hebben om te kunnen zeggen: "Dit is waar het echte probleem is." Weet je?
Dez Blanchfield: Ja. De laatste voor jou, en het ding dat me opvalt, is dat we, wanneer we dit doormaakten, vaak de neiging hebben om speciale vaardigheden in te brengen als we aan prestatieproblemen denken. Ze komen met 20 jaar ervaring, ze kijken ernaar, en ze zijn een beetje, je weet wel, de klassieke grap van de man die de engineeringwinkel binnenloopt en een kleine kleine hamer heeft en de machine op de juiste plek slaat en dan zegt, "Dat is een fix van $ 15.000, " en mensen zeggen: "Daar betalen we niet voor", weet u, omdat het vijf minuten duurt. En hij zegt: "Wel, dat werk van vijf minuten kostte 15 jaar ervaring om het op te lossen en het heeft u miljoenen bespaard."
Voor mij lijkt het, weet je, er is een middelste proces van, mensen doorlopen dit ding en zeggen: "Oké, breng de speciale vaardigheden naar binnen, los het probleem op, het zal verdwijnen." Maar wat ze toen hebben gedaan is ze hebben er gewoon een pleister op gedaan, toch? In tegenstelling tot een scenario waarin, van wat ik hier kan zien, waar dit mogelijk is, ja ze misschien enkele prestatieproblemen hebben aangepakt waarvan ze dachten dat ze er last van hadden, maar het lijkt mij juist op dat moment gewoon om deze 24 / 7 soort, je weet wel, een reeks ogen die de omgeving in realtime bekijken.
Je komt echt uit de buurt van het scenario dat DBA's om vier uur 's ochtends wakker worden, omdat er rapporten worden uitgevoerd. Is het het geval - en misschien is het retorisch - maar is het het geval dat mensen snel overstappen van het zoeken om te investeren in een product om het een bepaald probleem op te lossen, maar wordt het dan meestal gewoon deel van het DNA?
Bullett Manale: Ja, en het varieert van plaats tot plaats, maar ik bedoel, ik heb mensen die het product oorspronkelijk kochten, zoals in 2006, en ze hebben drie verschillende banen bij verschillende bedrijven gehad, en ze zijn naar binnen gegaan en, wanneer ze naar dat volgende bedrijf gaan, promoten ze dit als iets om te krijgen omdat ze een workflow hebben. En noem het zo, ik haat het zo te noemen, maar, weet je, die workflow heeft betrekking op dit product en ze zijn er dagelijks aan gewend en het helpt hen, en dus willen ze niet iets nieuws leren.
Maar absoluut. Ik bedoel, meestal laten we mensen dit product downloaden, niet omdat ze een budget hebben en dat ze uitgaan en ze zeggen: "Hé, we hebben dit prestatiebudget, we moeten doen een proof of concept, en we moeten instappen en erachter komen, een evaluatie doen en al dat soort dingen. ”Meestal gebeurt er een probleem met een exemplaar van SQL en zoeken ze hulp los dat probleem op. Ze gaan onze tool downloaden, krijgen het probleem opgelost en dan realiseren ze zich dat dit, de tool zelf meer gaat doen dan alleen het probleem oplossen dat ze destijds hadden, dat het hen daadwerkelijk zou helpen de algehele prestaties te verbeteren en andere problemen voorkomen en vooruitgaan. En dat is zeker. En je kunt dit hulpmiddel zeker blijven gebruiken om de omgeving continu af te stemmen, omdat je altijd niet alleen kunt zien wat er nu is gebeurd, maar ook wat er vorige week, vorige maand, vorig jaar is gebeurd en dat kan vergelijken met wat er gaat gebeuren. morgen. Je weet wel? Dat soort dingen.
Dez Blanchfield: Ja.
Bullett Manale: Dus zeker.
Dez Blanchfield: Perfect. Dus je hebt gezegd, je hebt iets gezegd over - ik ga even afronden voordat ik mijn hand terug geef aan Eric om te sluiten. Een van de dingen waar ik altijd in geïnteresseerd ben, is, weet je, hoe mensen het in handen krijgen? U noemde het downloaden. Wat is de samenvatting van 30 seconden over hoe ze het te pakken krijgen, een kopie krijgen, het opdraaien en ermee spelen, en wat ze infrastructuur nodig hebben, gewoon om een exemplaar te krijgen.
Bullett Manale: Dus dat wordt het, je gaat naar IDERA (idera) .com. IDERA.com is het bedrijf, en als u die website bezoekt - en ik kan het u hier echt laten zien - weet ik niet of ik mijn scherm nog steeds deel, maar als u naar de productenpagina gaat, ga dan naar de diagnose Manager-koppeling, er is een kleine downloadknop en u kunt de build gewoon downloaden nadat u uw informatie hebt ingevuld. Ze zullen je om de 32- of 64-bits build vragen en je gaat naar de races, zoals ze zeggen.
Dez Blanchfield: En zal het op een laptop draaien voor iemand om ermee te spelen, of moeten ze het ergens op een server laden?
Bullett Manale: Nee, nee. Wat ik je vandaag liet zien, draaide allemaal op mijn laptop. Nu heeft mijn laptop 32 optredens en een 8-coreprocessor, maar het is nog steeds een laptop. Maar het hoeft niet per se zoveel middelen te hebben om je vraag te beantwoorden. De evaluatie zelf is 14 dagen goed, maar je bent meer dan welkom om het een langere proefperiode te geven. Als u ons even belt, kunnen we dat voor u uitbreiden als u dat wilt.
Dez Blanchfield: Ik denk dat dat iets moet zijn om mee te nemen, want dat ga ik zeker doen. Ik denk, weet je, vanuit het uiterlijk van de dingen lijkt het me een simpele gedachte om het te downloaden en ermee te spelen. Ga waarschijnlijk naar een van je omgevingen en kijk gewoon wat je kunt zien, omdat ik vermoed dat - zoals alles wat ik de afgelopen 20 jaar in een database-achtergrond heb gezien, wat mij ouder maakt - als je eenmaal ziet wat er onder de kap, het is verbazingwekkend wat je beseft dat je snel kunt repareren en gewoon weinig winst kunt behalen.
Geweldig, bedankt voor de demo. Het was echt geweldig. Bedankt voor de tijd om de vragen te bespreken.
Bullett Manale: Graag gedaan . Bedankt voor-
Dez Blanchfied: Eric, ik ga je teruggeven.
Eric Kavanagh: Ja, we hebben echt een goede vraag van het publiekslid. Je hebt hier in je presentatie over gesproken en ik heb hier eigenlijk over getweet omdat het zo'n geweldig citaat was. U zei dat u geen tool wilt gebruiken om de prestaties te controleren die uw prestaties negatief beïnvloeden.
Bullett Manale: Juist. Dat is juist. Dat is nogal een belangrijk onderdeel van een tool voor prestatiebewaking, omdat het geen prestatieproblemen veroorzaakt. Precies goed.
Eric Kavanagh: Precies. Nou, het is net als die verdomde - het is net als de anti-virale programma's die gewoon schade kunnen aanrichten aan systemen. Ik bedoel, ik heb een aantal verschillende technologieën gebruikt voor het uitzenden waar het antivirusprogramma van start gaat en je stream zal afkappen. Er zijn dus dingen die je niet verwacht, maar de vraag heeft betrekking op die specifieke opmerking die je hebt gemaakt. En wat voor soort hits zie je? Is het twee procent, is het vijf procent, is het een procent? Heb je nummers die je naar ons kunt gooien?
Bullett Manale: Nou, ik bedoel, de uitdaging met deze vraag is dat, weet je, een deel van de discussie was waar we het eerder over hadden. Ik kan u het geven - het is meestal ongeveer een tot drie procent om uw vraag te beantwoorden. Maar er is meer uitleg die volgens mij nodig zou zijn, namelijk dat we je veel manieren bieden om de tool te vertellen wat je wilt monitoren, toch? En zo gaat het daarnaar terug. Nou, ik wil misschien een voorbeeld krijgen van elke zoekopdracht die wordt uitgevoerd. Dus ik wil een tool hebben die flexibel genoeg is om die in te schakelen, zodat ik dat kan zien.
En dus omvat een deel van die flexibiliteit, weet je, zijn er kosten aan verbonden. Als ik meer gegevens moet verzamelen omdat ik een voorbeeld wil van elke zoekopdracht die de laatste 20 minuten wordt uitgevoerd, weet u, 20 minuten, ik kan dat inschakelen en dat kan. En dus, maar over het algemeen, ja, is één tot drie procent wat we zien, in termen van overhead. Maar dat zal variëren, en het meeste daarvan zal afhankelijk zijn van je dingen die je in- en uitschakelt, in termen van je drempels, hoeveel gegevens je wilt verzamelen, je polling-intervallen, al dat soort dingen dat.
Als u naar de instantie zelf gaat die u beheert, is een van de dingen die u ziet, dat we meerdere polling-intervallen hebben die u kunt opgeven. En dat is gewoon omdat we dat willen, weet je, ik hoef niet alles te controleren - als ik een hartslagcontrole op een instantie wil doen, hoef ik de CPU en al het andere niet mee te pollen als ik ' doe het elke 20 seconden. U hebt dus meerdere polling-intervallen die u kunt opgeven.
U hebt ook, zoals ik al zei, uw zoekopdracht voor zoekopdrachten die u kunt opgeven. En dit kan voor elke instantie afzonderlijk worden gedaan, dus u kunt echt inspelen op die specifieke instantie in termen van wat u wilt controleren. Voor mijn wachtstatistieken en wachtmonitoring kan ik die in- of uitschakelen. En ik kan het vertellen om alles vast te leggen, ik kan het vertellen, weet je, wat ik wil vastleggen en wanneer ik het wil vastleggen. Dus veel daarvan zal ook - Je moet rekening houden met wat je doet, in termen van wat je de tool vertelt om te controleren.
Maar over het algemeen is wat ik zou zeggen, zoals ik al zei, ongeveer één tot drie procent. We verkopen deze tool al lang - sinds, zoals ik al zei, rond 2003 of 2004 - en we hebben duizenden klanten, dus ik kan je verzekeren dat, weet je, we hebben geen - we proberen onze het beste om geen prestatieproblemen te veroorzaken in naam van de uitvoering.
Eric Kavanagh: Ja, dat is echt goede informatie. Ik dacht gewoon dat dit een briljant citaat was, want weet je, nogmaals, je wilt niet het doel verslaan van wat je probeert te bereiken, toch?
Bullett Manale: Precies.
Eric Kavanagh: En ik waardeer de vraag van Robin ook; dit is echt een uitstekend platform om DBA's te helpen de vele verschillende aspecten en dimensies en lagen van waar we het over hebben te begrijpen. En ik denk dat het concept van een gesprek met uw gegevens hier zeer geschikt is, omdat u, tot uw punt eerder, meestal niet bij de eerste poging zult achterhalen. Je moet wat tijd besteden aan het bekijken van de gegevens, het bekijken van historische gegevens, die synthese in je hoofd doen. En dat is de taak van de mens, toch? De baan van het beroep dat daar achter zit en op een redelijk regelmatige manier warmte van het bedrijf haalt, om die klus te klaren en de treinen op tijd te laten rijden, toch?
Bullett Manale: Absoluut.
Eric Kavanagh: Nou, mensen, dit is weer een fantastisch evenement geweest. Als een vraag die u stelde niet is beantwoord, laat het me dan zeker weten. Stuur een email naar . We archiveren al deze evenementen, dus u kunt altijd naar InsideAnalysis.com gaan om het archief te vinden, of naar onze partner, Techopedia.com. Als u aan de rechterkant van hun pagina kijkt, ziet u Evenementen en de daar vermelde webcasts. Als u op Meer evenementen klikt, kunt u alle webcasts zien die we daar vermelden, verleden, heden en toekomst.
En daarmee gaan we u vaarwel zeggen. We hebben nog vijf webcasts voor de rest van dit jaar, mensen. We kunnen er nog een plannen. Maar anders gaat het door tot 2017. De ed cal is uit. Laat het ons weten en als je iemand hebt die hun technologie wil demonstreren, stuur dan een e-mail naar.
Daarmee gaan we je vaarwel zeggen, mensen. Nogmaals bedankt voor je tijd en aandacht, we zullen de volgende keer met je praten. Wees voorzichtig. Tot ziens.
