Prestatiespel: zeg vaarwel tegen latentie

Door Techopedia Staff, 9 mei 2016

Takeaway: Host Eric Kavanagh interviewt Mark Madsen, Dez Blanchfield en Bullett Manale over latentie en prestaties.

Je bent momenteel niet ingelogd. Log in of meld je aan om de video te bekijken.

Techopedia Content Partner

Techopedia Staff is aangesloten bij Bloor Group en kan worden gecontacteerd met behulp van de opties aan de rechterkant. Klik hier voor informatie over hoe we samenwerken met partners uit de industrie.

• Profiel
• Website

Eric Kavanagh: Dames en heren, hallo en weer welkom bij Hot Technologies! Ja inderdaad! Mijn naam is Eric Kavanagh, dit is onze Hot Tech-show, een samenwerking met onze goede vrienden van Techopedia. Spring online naar Techopedia.com voor het laatste nieuws op het brede gebied van bedrijfstechnologie; ze dekken natuurlijk ook consumentenartikelen. We richten ons op de onderneming hier in ons programma, dus dat is wat we vandaag gaan doen.

Er is echt een plekje over jou, genoeg over mij, sla me op Twitter @eric_kavanagh, ik hou van Twitter, ik hou ervan om dat soort dingen te bekijken, het is een geweldige manier om in contact te blijven met mensen en goede gesprekken te voeren, en one-on -een gesprekken.

Dus waar hebben we het over? Dit jaar is hot, dit is een heel universum van kansen waar we vandaag naar kijken in de wereld van informatiebeheer, en waar we vandaag over praten zullen vragen zijn, het gaat vragen versnellen.

Ik denk dat ik de titel 'Performance Play: Say Goodbye to Latency' ben vergeten te noemen. Wel, wie wil latency? Niemand wil latentie, latentie is wanneer je daar zit, op de knop klikt en wacht tot er iets gebeurt, en niemand wil dat. De kinderen vinden het niet leuk, ze vinden het niet cool, de volwassenen vinden het ook niet leuk. We zijn allemaal verwend door de snelheid van het internet, en we willen dingen snel, we willen dingen nu, en daar gaan we het vandaag allemaal over hebben in onze show.

Analist Mark Madsen is vandaag bij ons van Third Nature, een van onze vaste klanten. Onze nieuwe datawetenschapper, Dez Blanchfield, belt vanuit Sydney, Australië. En dan Bullett Manale, ja inderdaad, zo heet hij eigenlijk, het zijn twee T's. Bullett Manale is aanwezig terwijl onze gast uit Idera, een heel, heel interessant bedrijf, veel dingen doet. Ik ken ze al, waarvan ze een tijdje geleden een bedrijf kochten met de naam Precise. Ik wist dat hun CEO Zohar Gilad heette, hoe is dat voor een naam? Hij was echt een slimme kerel.

Maar mensen, u speelt een belangrijke rol in deze webcast in de vragen die u stelt, dus wees niet verlegen, stuur uw vragen op elk gewenst moment - u kunt dit doen met behulp van de Q & A-component van de webcastconsole, dat is daar beneden in de hoek rechtsonder. Je kunt ook met mij chatten en ik zal het met de sprekers chatten. We hebben al iemand die vanuit Italië belt, dus: “Ciao, ciao. Kom stai? ”Oké, daarmee ga ik Mark's eerste regel duwen, ik ga het dek aan Mark overhandigen. Mark, je hebt nu de WebEx. Haal het weg, de vloer is van jou.

Mark Madsen: Bedankt, Eric. Ik ga echter niet in het midden beginnen, ik begin bij het begin. Dus slechts een paar opmerkingen om de discussie met Dez en Idera op gang te brengen, een soort staat met ontwikkeling, en databases en operaties. En weet je, als je hiernaar kijkt, hebben we dit soort twee wereldenproblemen nog steeds in de database- en applicatiemarkt, omdat ontwikkelaars de DBA's zien als de mensen die ze lastig vallen. Je moet datamodellen bouwen, daar heb je geen toegang toe, je kunt dat ding niet maken, je kunt geen index op elke kolom van elke tabel in de database zetten om het sneller te maken. En natuurlijk, waarom hebben we de modellen nodig? Het zijn alleen datastructuren, als we ze veranderen, kun je ze niet gewoon in een serienummer schrijven?

Het probleem is dat ontwikkelaars code en toepassingen kennen, maar twee dingen die ze vaak niet weten, zijn gelijktijdigheid, gelijktijdig programmeren en databases en de besturingssystemen eronder. Als kernelontwikkelaar en besturingssystemen en databases, kan ik zeggen dat gelijktijdigheid en parallellisme erg moeilijk zijn, en dus veel dingen die je leert om goede prestaties uit je code te halen, beginnen echt uit elkaar te vallen wanneer je werken met een database. En de prestaties zien er geweldig uit, de testomgeving ziet er geweldig uit, en de Q & A-omgeving, en dan raakt het het echte systeem, en dan is het plotseling niet zo geweldig. Omdat het veelzijdig is, hoe de code werkt met de database, hoe het werkt met de omgeving, en echt eenvoudige kleine praktijken, kunnen drastische effecten hebben, afhankelijk van de schaal die u gebruikt.

En wanneer u begint te praten over externe toepassingen, kunnen externe toepassingen, webtoepassingen, natuurlijk heel moeilijk zijn, omdat dingen geweldig zijn tot ze opeens plat gaan liggen, en dat zijn ze niet. Je zult deze interessante plateaus raken die veel nuance vereisen om te begrijpen.

De keerzijde van de dingen is de DBA-weergave. De DBA-mening is dat er operaties zijn, ze besteden het grootste deel van hun tijd, 80 tot 90 procent, in ops, en misschien 10 tot 20 procent omgaan met de ontwikkeling dingen die vooraf gaande is. Vanuit dit perspectief betaal je nu of je betaalt later, en als je al je tijd vooraf doorbrengt, dan heb je later een veel betere kans, in tegenstelling tot ontwikkeling die de neiging heeft om een ​​functie te verkennen ruimte, en proberen erachter te komen hoe je dingen het beste kunt doen. En dus hebben we problemen, en nu hebben we incompatibele methoden: continue implementatie, het oprollen van uw apps wanneer ze klaar zijn, periodiek code pushen, werken in een winkel waar ontwikkelaars worden geoefend. Dit soort dingen versnelt de ontwikkeling, maar alle praktijken rond de database en wat DBA's doen en wat systeembeheerders zijn opgeleid om te doen, IT-ops-praktijken hebben geen gelijke tred gehouden.

Als u erover nadenkt, werken de meeste DBA's in een veranderingsomgeving versus een continue implementatieomgeving. Het draait allemaal om stabiliteit en controle, versus snelheid van verandering en omkeerbaarheid. Continue implementatie, als u niet terug kunt komen uit verandering, zit u in de problemen, dus alles moet worden gebouwd om gemakkelijk omkeerbaar en code-omschakelbaar te zijn, wat zeer niet de manier is waarop relationele database, ontwikkelingspraktijken en beheerpraktijken hebben gewerkt .

U ondervindt ook de problemen om proactiever te moeten zijn als u kunt, als een DBA, want tegen de tijd dat u over een probleem hoort, vullen honderdduizend mensen klachtenformulieren op uw website in. Dat laat je nog wat nieuwe dingen nodig die je niet uit je oude omgeving haalt. Weet je, dingen als betere monitoring en alarmering. Tegelijkertijd vermenigvuldigen databases zich, we hebben meer applicaties dan ooit om meer dingen dan ooit te ondersteunen, ze zijn binnen, ze zijn buiten, ze zijn overal. En meer onafhankelijke gegevenssets voor analyses, mensen starten overal databases op, omdat het nu natuurlijk eenvoudig is, u kunt een virtuele machine instellen. Als u een cloudprovider of een interne cloud heeft, kunt u dingen meteen laten verschijnen en dit verandert uw hele inkooptraject.

Het oude inkooptraject was: "Ik heb tijd om een ​​server te krijgen, deze in een rack te plaatsen, ruimte toe te wijzen, opslag te krijgen, de database te installeren en dingen te doen", versus iemand die een creditcard veegt en binnen vijf minuten bezig is. Als u dat doet, werkt die moderne ontwikkelomgeving in een tempo dat heel anders is, en het is dus gemakkelijk om databases te maken, en dat creëert gewoon dit probleem van proliferatie, als niets dat we eerder hebben gezien. En dit is nu al tien jaar aan de gang, dit is voor niemand nieuws, maar het betekent ook dat de operationele omgevingen steeds complexer zijn geworden.

De hele client-serveromgeving is echt veranderd, omdat het geen client-serverwereld meer is. Destijds had u een server, u had een database, als er iets mis was, wist u naar welke server u moest gaan, u wist hoe u de bronnen erop moest beheren, omdat de beste praktijk één database was, één server. Virtualisatie begon dat uit elkaar te halen, cloud breekt het zelfs nog meer, omdat wat u denkt dat een databaseserver is, gewoon software is. Dus de omgeving is niet echt. Het is wat de omgeving bevat die de realiteit is, en dat kan een rek van blades zijn of een grote server in stukken gehouwen, je weet het niet echt.

Alles rondom databasebeheer en prestatiebeheer, en welke databases zijn gebouwd rond strakke controle met één server, of een handvol servers en een paar databases, u kunt niet alles beheren. Je zit daar op een machine, maar bandbreedte kan niet gemakkelijk worden gepartitioneerd door de virtuele managers, en dus kan alles in orde zijn met geheugen en CPU, maar je hebt knelpunten in een bron die niet kan worden behandeld, en dan wanneer je probeert het te repareren, het oude model zou hard aan het werk zijn geweest, een grotere server krijgen en zoiets doen, nu kan het heel eenvoudig zijn, voeg gewoon een virtuele cursus toe, voeg gewoon geheugen toe aan de VM en het is opgelost. Maar wat gebeurt er als uw VM op een overvolle server staat en moet migreren? Of wat gebeurt er als je de grootte van een AWS-systeem hebt en de maximale grootte is bereikt, waar ga je nu heen?

Dus je hebt al deze problemen waarbij de omgeving nu deel uitmaakt van de database, je verpakt een omgeving met een database, alle speciale bronnen, alles in de applicatie dat deel uitmaakt van de configuratie, de configuratie wordt daar naar buiten geduwd. Dit komt uit de databaseomgeving, het is een stuk moeilijker te beheren en te controleren.

Als je kijkt naar wat de databasecentra hebben gedaan, hebben ze op hun handen gezeten, toch? We zijn afgestapt van dit idee om databases en servers als huisdieren te behandelen. Servers hebben namen, je behandelt ze alsof ze individueel unieke dingen zijn, je behandelt ze als vee, het beheert een kudde. En het probleem met het beheren van kuddes is dat als je ze niet onder controle hebt, ze uiteindelijk kunnen stormen, en een stormloop is geen goede zaak. We hebben betere monitoringtools nodig, we hebben betere manieren nodig om hiermee om te gaan en weten wat er is getroffen. In het oude model was het eenvoudiger omdat je operaties en al je besturingssystemen je dat vertelden, maar wanneer je servernaam een ​​UPC-code is, is het moeilijk om erachter te komen.

U kunt zich geen valse meldingen veroorloven, u kunt zich geen dingen veroorloven die zeggen: "Er is een probleem met deze machine en die machine host 30 databases." U kunt het zich niet veroorloven dat dingen u geen geschiedenis geven. Monitoring-consoles zijn geweldig als ze oplichten, maar als het rode lampje weer groen wordt en je weet niet waarom, en je hebt geen geschiedenis om terug te gaan naar wat eraan vooraf ging, en wat de context was, je zit in de problemen. We hebben systemen nodig die voor ons zullen monitoren, we moeten beter monitoren, omgaan met de vluchtige intermitterende problemen die die gegevenshistorie onderhouden.

Betere dingen en eenvoudige metrics-drempels die ons belangrijke metrics opleveren, maar ons niet rechtstreeks begeleiden naar wat normaal is, wat abnormaal is en hoe vaak deze problemen optreden. Waar we het echt over hebben, is een combinatie van monitoringomgeving en het omgaan met prestaties, en de leveranciers hebben op hun handen gezeten. Ze hebben ons geen betere tools gegeven. We hebben systemen met meer CPU en geheugen dan we weten wat we ermee moeten doen, en toch vertrouwen we nog steeds op handmatige interventiemodellen, we hebben de machine niet aan het werk gezet, ons begeleid, om ons op het punt van problemen te krijgen, we zijn nog niet in deze nieuwe stijl terechtgekomen: "Er is hier een probleem, je kunt dit doen om het op te lossen, " of: "Er is een prestatieprobleem, het is eigenlijk met deze specifieke SQL-instructie, hier zijn drie dingen die je zou kunnen doen gebruiken om die SQL-instructie op te lossen. ”Heuristiek toepassen, machine learning-modellen toepassen die naar de gebruikspatronen van uw systeem kunnen kijken om problemen te herkennen en valse waarschuwingen te voorkomen. De machine gebruiken om te doen wat de machine het beste doet, om de DBA te vergroten, of om de persoon die te maken heeft met prestatieproblemen te vergroten.

Dat is de nieuwe manier, in tegenstelling tot de oude stijl. Er is een probleem met deze database, dingen zijn traag, en dus hebben we nieuwe technieken, nieuwe manieren om het te doen, en we zouden die moeten toepassen, en dat is waar de markt naartoe gaat. Je ziet het beginnen op te duiken, niet bij de grote leveranciers, maar bij externe bedrijven, en dit weerspiegelt iets dat 20 jaar geleden gebeurde toen de databaseleveranciers niet één ding verschaften om de systemen te helpen beheren. Dus dat is een soort van wat de richting van de markt is, en daarmee wil ik het graag teruggeven aan Eric.

Eric Kavanagh: Oké, ik ga het overhandigen aan Dez. En Dez, haal het weg, de vloer is van jou.

Dez Blanchfield: Bedankt, Mark. Je hebt het fantastisch gedaan om de technische component ervan te dekken. Ik ga er vanuit een iets andere invalshoek op uit om te benadrukken wat er in de rest van de wereld is gebeurd, wat betreft de impact op bedrijven en de databases om hen heen. Laat me gewoon naar mijn eerste dia springen.

Achter de technische kant van de dingen en de ontwikkelaarskant van dingen zie ik dat bedrijven de uitdaging van met name gegevens en databases in het bijzonder moeten aangaan, en uiteraard hebben we deze belangrijke verschuiving naar dit concept van big data, maar databases zijn nog steeds het hart en de ziel van waar organisaties hun bedrijfsinformatie bewaren, en het gaat van de voordeur helemaal naar de backoffice. Elk deel van de organisatie wordt geraakt door een soort database en aangedreven door een database, en zeer zelden ga ik in op projectdiscussies of een vorm van innovatief strategisch gesprek in een organisatie waar het onderwerp van de database of het databasesysteem komt niet naar voren, en er zijn altijd vragen over het soort dingen waar we zojuist over gehoord hebben, in prestaties en beveiliging en hoe komt ontwikkeling deze uitdaging aan, en waar passen de databases bij, en zijn we ons bewust van omgevingen en toepassingen omgevingen praten, hoe zit het met apparaten en mobiliteit?

Het is nog steeds een heel, heel populair onderwerp, en het is al heel lang een onderwerp in het grote geheel van dingen voor zover moderne technologie gaat. Tot zover geloof ik dat het een feit is dat bijna alles wat we doen in ons dagelijks leven, dat wil zeggen dat ons dagelijks leven wordt ondersteund door een vorm van database. Wanneer we nadenken over alle dingen om ons heen, of het nu een factuur is die elke dag in de post komt voor een dienst die we kopen, wordt het onvermijdelijk afgedrukt door een systeem dat tegen een database praat, en we zijn erbij. Onze telefoons hebben databases met de contacten en oproeplogboeken en andere dingen.

Waar we ook gaan, er is een vorm van database achter de talk en de systemen die we gebruiken, en vaker wel dan niet, ze zijn redelijk transparant voor ons, maar het feit is dat ze er zijn. Dus ik dacht dat ik snel zou vertellen waarom dit in een zeer korte periode een beetje een probleem is geworden. In het begin kwam het concept van de database van deze mooie heer, Edgar Codd. Terwijl hij bij IBM werkte, veranderde hij de wereld op het gebied van gegevensbeheer door een concept te creëren dat we nu een relationele database noemen.

In het begin was de database een database en het leven was goed, het was redelijk eenvoudig, zowel in kolommen en referenties, enzovoort, en tabellen, en het ontwikkelen van software was vrij eenvoudig, en de prestaties waren niet echt een groot probleem - het was een nieuwe opwindende technologie. We hebben toegang gekregen tot de databases via een vorm van terminal, en je kunt alleen echt zoveel ravage creëren aan het einde van een 3270-terminal op een mainframe, en steevast andere typen terminals, die andere systemen kwamen langs. En in de meeste gevallen leken de oude-stijl terminals erg op wat webomgevingen nu zijn, en dat is dat je een formulier op het scherm op de terminal zelf zou invullen en op Enter zou drukken en het zou gaan, het zou schiet weg als één pakket, als een verzoek, en het back-end systeem zou het afhandelen. Dat is in wezen wat er tegenwoordig gebeurt in een webbrowser, wanneer je een link in een webbrowser typt en die vorm gaat het meestal niet in realtime terug naar het systeem, hoewel met AJAX deze dagen niet helemaal de geval.

Maar toen gebeurde er iets, de toekomst kwam, en meer recent het internet, en bijna gisteren, in een sec web 2.0, en net om de hoek hebben we het internet der dingen. En in het proces van de toekomst, is de wereld van de database net ontploft, en de interacties met databases zijn een ding geworden dat we allemaal standaard deden, het was geen geval dat je ergens naartoe zou gaan om iets te doen, zoals kopen een ticket voor een vliegtuig, en naar de andere kant van de planeet willen reizen, moest iemand in de terminal al je gegevens typen en naar een database gaan en een ticket afdrukken.

Bijna alles wat we nu doen, of het nu een taxi is op Google met een applicatie, of het nu springt op internetbankieren, alles wat we doen op een dagelijkse basis, met een soort systeem, het wordt aangedreven door een database. En toen internet opkwam, was dat een beetje gemakkelijker voor ons, ons dagelijks leven via een webbrowser, en toen kwam web 2.0 en dingen werden mobiel, en de schaal van dingen explodeerde gewoon. In feite is mijn favoriete regel in dit onderwerp: "Het internet heeft alles met elkaar verbonden, web 2.0 heeft het mobiel en sociaal gemaakt, en dingen zijn heel, heel groot geworden en nu hebben we internet en dingen en, en IoT … Yikes !!" We zijn ons nog niet eens begonnen de impact van het internet der dingen op de wereld voor databasesystemen voor te stellen.

Dus in moderne termen, wat we vroeger als een terminal beschouwden, zijn dit in feite dingen geworden, het zijn mobiele telefoons, het zijn verschillende soorten tablets, ofwel persoonlijke consumenten- of enterprise-grade groot scherm tablets, het is laptops en het is de traditionele desktop in een of andere vorm. In die ene afbeelding ziet u bijna elke vorm van interface die we nu gebruiken om te praten met databasesystemen en apps die worden aangedreven door die, van de kleine gadgets in onze handen die rondlopen en we lijken te zijn gelijmd, allemaal de weg naar de iets grotere versies, en iPads, en andere tablets en Microsoft Surfaces, naar alledaagse laptops, wat nu steevast het geval is in professionele omgevingen enzovoort. Mensen hebben de neiging om een ​​laptop te krijgen en geen vaste desktop, maar zij zijn naar mijn mening de moderne terminal en een deel van de reden dat databases allerlei uitdagingen ondervinden in de managementprestaties van ons leven, en niet alleen in ontwikkeling.

Ik neem aan dat dit een van de grootste uitdagingen is waarmee bedrijven nog steeds dagelijks worden geconfronteerd. Iedereen dacht dat databases onze enige problemen waren, dat zijn ze niet. Dus waar gaat het allemaal om? Welnu, als we van het ene eind naar het andere gaan met alle dingen die verband houden met databases, in commerciële zin, en Mark's de technische componenten heel, heel goed behandelde, maar in commerciële zin, als organisatie, denken we aan databases. We hebben te maken met zaken vanaf het basisontwerp en de ontwikkeling van het front-end. Wanneer een bedrijf start, zullen ze denken aan het ontwikkelen van applicaties, het ontwikkelen van een mogelijkheid of zelfs het implementeren van een bestaande applicatie in een of andere vorm. Er moet een vorm van ontwerp en ontwikkeling plaatsvinden en er moet veel nagedacht worden over de manier waarop deze databasesystemen worden geïmplementeerd en ondersteund en beheerd, en prestaties worden bijgehouden enzovoort.

De integratie van de databaseomgeving en applicaties, en de soorten API, de soorten toegang die nu worden aangeboden, worden steeds uitdagender, complexer. Dagelijks beheer, ondersteuning en back-ups, nogmaals, dit zijn dingen waarvan we dachten dat ze waren opgelost, maar toen werd de schaal plotseling veel groter, en dingen gingen sneller en het volume was zoveel groter; de grootte van de omgevingen moesten de databasesystemen de snelheid ondersteunen waarmee transacties worden verplaatst.

Denk aan een database in een zeer, zeer hoogfrequente handelsomgeving, er is gewoon geen manier waarop mensen dat kunnen bijhouden, het is gewoon een cluster van machines die vechten tegen een ander cluster van machines om hoogfrequente handel te doen, kopen en verkopen, en het volume op welke die transacties gebeuren. Denk aan een modern scenario, zoals een vroege release van een Netflix-film waarin je het niet hebt over slechts honderden of duizenden, of zelfs honderdduizenden, mogelijk miljoenen mensen die die film willen zien vanaf het moment dat deze wordt uitgebracht. Al die informatie wordt vastgelegd en bijgehouden en vastgelegd en geanalyseerd in een databaseplatform.

En dan is er de altijd-aan-wereld waarin we nu leven, 24/7, niet alleen de Zon volgen maar er is altijd iemand om middernacht die iets wil doen, en kantooruren volgen de Zon over de hele wereld. Dus uptime en beschikbaarheid zijn standaard, zijn nu een klimaat, een storing is gewoon niet acceptabel. En redundantie, als er een prestatieprobleem is of als we een onderhoudsvenster nodig hebben om een ​​upgrade of een patch of een beveiliging uit te voeren, moeten we echt van de ene databaseomgeving naar de andere kunnen schakelen en dit naadloos en automatisch doen.

Beveiliging en standaarden en compliance, we hebben de laatste tijd een aantal behoorlijk grote dingen gebeuren, met name GFC, en dus hebben we een hele reeks nieuwe uitdagingen om aan te voldoen rond compliance en beveiliging en bijpassende standaarden, en we hebben om daarover in realtime en idealiter in een dashboardvorm te kunnen rapporteren. We willen geen team apen naar een datacenter sturen om dingen te vinden, we hebben het systeem nodig om ons dat onmiddellijk en in realtime te vertellen.

En de twee grote leuke dingen waar bijna niemand over praat, we duwen ze over het algemeen onder het tapijt en hopen dat ze nooit hun lelijke kop opsteken, maar rampherstel en bedrijfscontinuïteit - dit zijn ook dingen die zouden moeten, want het grootste deel gebeurt automatisch, mocht dat nodig zijn.

We kunnen dagen doorbrengen met praten over het soort dingen dat mis kan gaan in database-omgevingen, en waar mensen over het algemeen op hebben gereageerd, maar nu hebben we systemen en hulpmiddelen nodig om dat voor ons te doen. Een voorbeeld is een datalek en dus, wanneer we aan databases denken, en ik stel deze vraag vrij open in verschillende vormen: wat gebeurt er met databases als we ons van de bal afhouden en er iets kritisch misgaat? Vooral als er geen systeem is dat de prestaties en beveiliging en andere belangrijke aspecten van het uitvoeren van databases bewaakt.

Wat er zou kunnen gebeuren is dit, dit is een screenshot van enkele van de recente inbreuken in de afgelopen twee tot drie jaar. Dit komt steevast allemaal uit een database-systeem, en steevast is er een probleem met de beveiliging of de controle, of de toegang die tot stand is gekomen, en in de linkerbovenhoek kijken we naar 152 miljoen Adobe-accounts, waar elk detail van die klanten werd overtreden. En als de juiste tools aanwezig zouden zijn geweest om het incident op te sporen en vast te leggen en de beveiliging te beheersen, hebben we sommige daarvan misschien vermeden, de eerste paar honderd records die werden gestolen, hebben ons mogelijk gewaarschuwd en we zouden stopte de volgende honderdvijftig miljoen.

Dan komen we bij het kernpunt van deze hele reis, die ons heeft meegenomen, namelijk: waarom hebben we betere systemen nodig? Waarom kunnen we niet gewoon meer lichamen naar dit ding gooien, dat we naar mijn mening echt het omslagpunt hebben overschreden, en ik geloof zeker dat er een geval is dat laat is gebleken, dat meer DBA's, beheerders en meer mensen naar dit probleem lost het probleem niet op. We hebben een betere set tools en een betere set systemen nodig.

Hier zijn mijn top vijf redenen die volgens mij dit ondersteunen, en ze zijn gerangschikt in volgorde van belangrijkheid, gebaseerd op wat ik zie in deze particuliere ondernemingen en staten die gereguleerde omgevingen zijn, de uitdagingen waarmee ze worden geconfronteerd met databaseomgevingen, en ze beheren.

Beveiliging en compliance - nummer één. Weet je, bepalen wie toegang heeft, waar hebben ze toegang, wanneer ze toegang hebben, hoe vaak ze toegang hebben, waar ze toegang toe hebben. Mogelijk de apparaten die ze daadwerkelijk hebben aangeraakt en de soorten dingen waar ze naar hebben gekeken, en de compliance die daar omheen gaat. Mensen 30 dagen later rapporten laten uitvoeren om ons te vertellen of alles goed is, is gewoon niet meer geschikt, het moet in realtime gebeuren.

Prestaties en monitoring - het lijkt een no brainer, maar dat is het steevast niet. Of we nu open-source tools of commerciële tools van derden gebruiken, we hebben steevast de boot op veel manieren niet gemist met de soorten prestatiebewaking die nodig is en de details en de mogelijkheid om op tijd te reageren .

Incidentdetectie en -reactie - het moet een instant realtime-ding zijn en we hebben steevast een systeem nodig om het voor ons te doen, of ons in ieder geval snel te waarschuwen zodat we het kunnen aanpakken, zodat de paar problemen die zich voordoen worden opgelost met snel, en niet uit de hand lopen.

Beheer en administratie - nogmaals, we denken dat deze problemen zijn opgelost, dat zijn ze niet. Het doel van problemen waarmee databaseteams worden geconfronteerd, met name de DBA's waar een systeem voor ons zou moeten zorgen, hebben we dat probleem nog niet opgelost, het is nog steeds een reëel ding.

En vanaf het allereerste begin met ontwerp en ontwikkeling, wanneer we beginnen met het bouwen van deze tools, bouwen we de database-omgevingen, kunnen we de juiste tools gooien naar ontwikkeling en testen, en integratie, platforms. Dit is nog steeds niet eenvoudig voor ons, en deze hele reis drijft het ons tot dezelfde boodschap dat we naar mijn mening betere systemen en betere tools nodig hebben om ons te helpen de resultaten te leveren die we nodig hebben onze databaseomgeving, dus de bedrijven die waarde genereren voor onze klanten. We kunnen niet alleen maar meer lichamen en meer DBA's gooien, de schaal is te groot, de snelheid is te snel en het volume is te hoog. Daarmee, Eric, kan ik misschien aan jou teruggaan.

Eric Kavanagh: Ik vind het geweldig, we hebben heel wat grond bedekt mensen, veel potentiële leads, en we gaan door en geven ze de sleutels aan Bullett in slechts een seconde.

Bullett Manale: Oké.

Eric Kavanagh: Oh, laten we het wegnemen en Bullett, nu geef ik het aan jou, en de vloer is van jou.

Bullett Manale: Oké, bedankt. Ik denk dat er veel goede punten zijn gemaakt. Ik wilde gewoon heel even praten over Idera, wie we zijn, en dan springen we erin. Ik ga het hebben over de tool waarvan ik denk dat veel van deze dingen waar we het over hebben, we kunnen soort set en soort van bespreken enkele van de gebieden waar deze, met deze tool, overeenkomen met het Diagnostic Manager-product.

Wat ik eerst wil doen, is je een beetje een achtergrond geven over wie Idera is; we zijn er al sinds ongeveer 2003, en dus zijn we begonnen met alleen SQL Server-tools, en dat is waar we ons vandaag op gaan concentreren, is het Diagnostic Manager-product. Maar je kunt alle emmers zien van dingen die we hier hebben, en we hebben onlangs, zoals eerder vermeld, Precise overgenomen en door acquisitie hebben we ook Embarcadero, en dus hebben we een vrij goede portfolio van producten.

In termen van prestatiebewaking, in termen van SQL Server, is het product waar ik het over wil hebben, waarmee deze onderwerpen worden afgestemd, Diagnostic Manager. Dit is een product dat al in de buurt is sinds het begin van de dagen van Idera, en ik heb het geluk om daar sinds ongeveer 2005 deel van uit te maken. En ik heb veel veranderingen gezien in termen van SQL Server, de verschuivingen van fysiek naar virtueel, al dat soort dingen die zijn gebeurd, en ook de behoeften van de DBA's naarmate de omgevingen groeien, en dat soort dingen.

Waar ik mee begon, was de typische gebruiker van ons product de DBA, en dus als we voor het eerst met mensen praten, potentiële klanten, zijn het meestal de DBA's waarmee we praten. We praten niet met de IT-managers of de directeuren, het kan op een bepaald punt op dat niveau komen, maar het eerste begin is dat de DBA een probleem heeft, de DBA probeert het probleem op te lossen, en vaak Ga en download en probeer het product als onderdeel daarvan. Je krijgt ofwel de datamanager of de DBA of de acterende DBA, de man die het geluk heeft om in sommige gevallen de meest technische in de kamer te zijn. Nu, wanneer u de grotere bedrijfsomgevingen bereikt, krijgt u uiteraard de volledige DBA's, meestal zijn dit degenen die de tool gebruiken. En ik ging door en voegde hier een kleine fout toe van Wikipedia. Het gaat een beetje over de verantwoordelijkheden van de DBA zoals Wikipedia zegt, dat is wat ze doen.

Als je de lijst hier doorneemt, veel van deze dingen, ik ga het niet aflezen, maar je krijgt veel van de typische dingen die je zou bedenken, en op een van hen heb je monitoring en het optimaliseren van de prestaties van de database, en dat is een behoorlijk grote. En wat interessant is, is dat wanneer je met de DBA praat, zij altijd degenen zijn die de schuld krijgen, als het gaat om problemen, en het is misschien niet hun fout, maar wanneer er een prestatieprobleem is, meestal met een applicatie die is gekoppeld aan een DBA-database, zij zijn degene die de schuld krijgen, dus ze zijn altijd op zoek naar de redenen waarom het niet hun schuld is. In veel gevallen kunnen ze deze tool, Diagnostic Manager, gebruiken om hen te helpen.

Maar uiteindelijk, als de database niet presteert, doen veel van deze andere dingen er niet echt toe, uw applicaties werken niet, dan maakt het voor veel van deze niet echt uit dingen. Eerst en vooral willen we ervoor kunnen zorgen dat de gebruikerservaring zoals we die kennen niet wordt aangetast, het is iets waar DBA's altijd naar streven. En ik denk dat, als je kijkt naar de redenen waarom mensen doorgaans het SQL Diagnostic Manager-product kopen en gebruiken, een van de eerste redenen is, waarschijnlijk niet de belangrijkste, niet de laatste of minste, maar over de hele linie gelijk is, en afhankelijk van met wie je praat, deze redenen, bijna een of twee zijn er altijd, er is een soort behoefte in de buurt.

Maar de eerste is gewoon in staat te zijn om die gecentraliseerde weergave van de instanties te hebben als een SQL die ze beheren. En het grappige is dat in veel gevallen, als je een DBA vraagt: "Hoeveel instanties kun je beheren?" Het aantal verandert zo vaak, dat ze in sommige gevallen niet echt zeker zijn. Je hebt dus meer nodig dan alleen alles op het scherm kunnen gooien. U wilt die informatie vastgrijpen, u wilt er iets van begrijpen, en dus dat is een van de dingen waar Diagnostic Manager zeker mee kan helpen, u een dergelijk inzicht in de omgeving kunnen bieden.

En het is niet alleen een blik op de omgeving, maar het is ook een mening waar de databasebeheerder zich prettig bij voelt en het is een console die centraal staat, als u wilt. Het is gemaakt voor een databasebeheerder. Er zijn veel monitoringtools die er zijn, er zijn veel performance-tools die er zijn, maar zoals ik al zei, de DBA wil uiteindelijk een tool die is ontworpen voor een DBA, omdat er veel dingen zijn die specifiek zijn voor wat ze doen in hun dag tot dag.

En dat gezegd hebbende, je hebt SCOM, je hebt HPF, je hebt al deze andere technologieën, maar ze willen iets dat specifiek is voor wat ze doen. Ik denk dat we op dit gebied kunnen helpen met dit product, je zult het zien als we er zo over beginnen. Het andere dat we zien met de DBA, dat is zeker een van de dingen die we eerder ook hebben besproken, is dat ze moeten kunnen zien wat er aan de hand is, uiteraard, en ze moeten kunnen kijken in de hele onderneming en een beetje gemoedsrust hebben om te weten wat er gebeurt. Maar tegelijkertijd zitten ze daar niet te staren naar consoles.

Herinner je je al die opsommingstekens die je op die lijst zag, die ik net heb getrokken? Ze moeten die andere dingen ook doen, dus het gaat niet alleen om wachten op branden. In veel gevallen zullen er vergaderingen zijn, of veel van de onderhoudsvensters met betrekking tot de databasebeheerder draaien midden in de nacht wanneer ze slapen, dus ze moeten de mogelijkheid hebben om terug te gaan en te zien wat er is gebeurd . In veel gevallen, als je iets niet opmerkt wanneer het gebeurt, zodra het probleem is verdwenen, of althans met SQL Server, wordt het een soort probleem waarbij je te maken hebt met de situatie waarin je niet heb nog restanten van dat probleem meer. En die problemen verdwijnen, en de restanten ook, wat betekent dat u minder problemen hoeft op te lossen, u minder informatie hebt om mee te werken.

Dat gezegd hebbende, dat is absoluut een van de dingen waar Diagnostic Manager je mee kan helpen, je die kijk in het verleden te geven om de informatie uit het verleden op te vragen: "Had ik een waarschuwing met blokkering, had ik problemen met deadlocking, hadden we dingen die gebeurden met betrekking tot onze middelen? ”Ik kan teruggaan en die informatie opvragen. Ik kan op specifieke punten in de tijd boren. Ik zou al die dingen rechtstreeks vanuit de tool kunnen doen.

Al deze dingen, ongeacht of het interne of een externe applicatie is, willen de DBA weten, omdat ze willen kunnen zien wat het probleem veroorzaakt. Het maakt niet echt uit of het iemand binnen de organisatie was of iemand buiten de organisatie die de code heeft geschreven; ze willen het nog steeds kunnen isoleren, zodat ze weten dat het probleem zich voordoet, en ze weten waar het vandaan komt.

Prestaties en verantwoordelijkheid zijn dus een belangrijk onderdeel van wat ons product doet. We kunnen al die details verstrekken, en wat best leuk is, is dat je de mogelijkheid hebt om door te gaan. Als er een knelpunt is, kunt u dat correleren met de toepassing, de gebruiker, de database, de query. En nogmaals, het is een soort rokend pistool. U krijgt een direct verband tussen wanneer deze zoekopdracht wordt uitgevoerd, wat doet deze? En het gaat niet alleen om de query zelf, in termen van het uitvoeren op zichzelf, maar wordt de query in de loop van de tijd ook erger? En die dingen kunnen ook worden beantwoord, met het product, wat zeker iets is dat als je proactief probeert te zijn, het leuk is om te kunnen zeggen: "Hé, hier is een vraag die slecht is verlopen, maar kijk er eens naar terwijl het verder loopt, kunnen we zien dat het nog erger en slechter wordt, daar kan ik iets aan doen. "

Als we hier het volgende gebied ingaan; en dit is waarschijnlijk - ik zou zeggen dat dit een van de groten is. Een van de vragen die ik stel, als ik ons ​​product laat zien, is dat ik de databasebeheerder altijd zal vragen: "Hoe hoor je over een probleem met je SQL Server-databases?" En het is erg grappig, omdat ze meestal - nu verleend - meestal naar ons product kijken, omdat ze in veel gevallen een specifieke behoefte proberen op te lossen. Maar het is interessant om het eerste soort dingen te horen - althans met SQL Server, is dat het soort van - weet je, in de begindagen van SQL Server had je SQL Server en toen had je Oracle. En iedereen had Oracle, en SQL Server leek een beetje op, bij gebrek aan een betere expressie, het roodharige stiefkind van databases, toen het voor het eerst begon.

En toen Microsoft er meer functies aan toe voegde, werd het een beetje meer een enterprise-tool. En het is duidelijk dat het sindsdien een heel eind is gekomen. Maar het punt is dat je op een keer zou kunnen beweren dat de databases vroeger niet als kritisch werden beschouwd. En dat is in de loop van de tijd veranderd. Daarom proberen mensen er in veel gevallen omheen te komen en zeggen: "Weet je wat? Ik heb al deze SQL Server-databases, ik probeer er grip op te krijgen. "En in plaats van te horen over problemen van de helpdesk of te horen over problemen van de specifieke mensen die - net als de gebruikers zelf, ze ' zijn op zoek naar manieren om daar omheen te gaan. Ze zoeken naar manieren om zich bewust te kunnen worden van die situaties voordat ze zich ooit voordoen.

En dus met Diagnostic Manager, dat is een van de dingen die we ook proberen te doen, is op zijn minst in staat te zijn om te maken dat de DBA de eerste is die op de hoogte is van die situaties, of die problemen, zodat ze kunnen doen er iets aan, precies wanneer ze gebeuren, of om nog een stap verder te gaan, om deze systemen te analyseren die het bewaakt. En om u proactief advies te kunnen geven om de prestaties van die instantie te verbeteren, en om dat regelmatig te kunnen doen. We moeten bijvoorbeeld een index toevoegen op basis van de werklast; dat soort dingen, de tools die dat ook kunnen. Dus dat zien we veel terug in de tool.

Het andere en het laatste dat op deze lijst staat, dat is nogal een algemene beschrijving, maar het is zeker het vermelden waard. En vooral, als je in de grotere soorten situaties op ondernemingsniveau komt, waar je veel instanties hebt, zal er altijd iets obscuurs zijn dat ik wil controleren, als ik de databasebeheerder ben, voor voorbeeld. En dus proberen we te anticiperen op wat de typische DBA gaat controleren.

Dat gezegd hebbende, zou je dat ook kunnen - er zal altijd iets nieuws zijn. Daarom hebben we u de mogelijkheid geboden om alle statistieken toe te voegen die u wilt controleren en beheren nadat het installatiepunt kan worden toegevoegd. Dus alle PerfMon-tellers, WMI-tellers, SQL Server-tellerobjecten; al die kunnen in de tool worden opgenomen. U hebt de mogelijkheid om extra zoekopdrachten toe te voegen die kunnen worden opgenomen in uw polling-intervallen.

En het laatste dat ook het vermelden waard is, is dat we kunnen toevoegen en communiceren met zowel vCenter als Hyper-V om de statistieken uit die omgevingen te kunnen halen. Omdat een van de dingen die we met de DBA hebben geïdentificeerd, is dat ze meestal geen specifiek onderdeel zijn van bewerkingen. En ze hebben meestal niet de vCenter-omgeving die voor hen beschikbaar is, of dat soort dingen die voor hen beschikbaar zijn.

En dus is het probleem dat als ze te maken hebben met een SQL Server-exemplaar en hun middelen zijn toegewezen, maar dat exemplaar is gevirtualiseerd, het lijkt alsof ze alle middelen ter wereld hebben, wanneer ze alleen maar controleren wat op het gastbesturingssysteem. De realiteit is dat er op de host 30, of 40, of 50 of 100 andere VM's zijn waartoe ze toegang proberen te krijgen en die dezelfde middelen hebben. En de enige manier om dat daadwerkelijk te zien, is door te communiceren met die andere omgevingen en met deze interfaces, in dit geval, wat we doen.

U hebt de mogelijkheid om die andere typen tellers aan de tool toe te voegen. Nu gaat het niet alleen om het controleren van die tellers, maar het gaat ook om het kunnen maken van die nieuwe tellers, die u aan het product introduceert, om ze deel te laten uitmaken van de tool, alsof ze een kant-en-klare metriek zijn . Een out-of-the-box ding dat u zou willen controleren; dus dat betekent dat ze in hun dashboards kunnen worden opgenomen. Het betekent dat u ze kunt toevoegen aan uw eigen aangepaste rapporten, dat u duidelijk drempels kunt instellen en erop kunt letten, maar ze ook baseline kunt maken en de drempels kunt instellen met enige kennis van waar u ze kunt instellen op basis van dingen zoals uw basislijnen en wat normaal is. Dus je hebt veel van dat soort dingen die ook in het product zitten.

Wat ik u een beetje heb verstrekt, is wat ik "de kernproducten voor Diagnostic Manager" noem, en ik kan doorgaan en u een voorproefje geven door in het product te gaan. Wat ik ga doen is deel mijn scherm, oké, en ga dit gewoon slepen. Dus wat je gaat zien, dit is de console voor Diagnostic Manager. En zoals ik al eerder zei, naar die eerste kernprestatie gaan, kunnen kijken naar dingen vanuit een soort enterprise-view. Er zijn veel verschillende voorbeelden van dat binnen de tool. We hebben een soort miniatuurweergave; we hebben meer een rasterachtige weergave. We hebben ook, in termen van flexibiliteit, we hebben ook een webgebaseerde console. De webgebaseerde console heeft andere weergaven die voor u beschikbaar zijn, zoals belangrijke kaarten en dat soort dingen. Maar het punt is, dat u die mogelijkheid hebt om dingen te bekijken en te bekijken op een hoog niveau. Maar als er zich problemen voordoen, ga je wat dieper in op de tool en zie je de specifieke prob en heb een manier om te begrijpen en te weten wat er aan de hand is. En dat is natuurlijk heel belangrijk.

Nu om te kunnen zien wat er in het verleden is gebeurd; als ik naar een probleem kijk dat gisteren of een week geleden is gebeurd, dan zul je in die situatie de behoefte hebben om naar een bepaald exemplaar van SQL te kunnen gaan. En het goede nieuws is dat als u weet hoe laat dat probleem zich in het product heeft voorgedaan, u rechtstreeks naar de geschiedenisbrowser kunt gaan. En ik kan wijzen op een specifiek tijdstip van de dag; het kan van een paar weken geleden zijn, het kan van gisteren zijn. Maar welke dag ik ook kies in de kalender, ik krijg dan de verschillende polling-intervallen te zien. In dat geval zie ik nu effectief wat ik zou hebben gezien als ik de console op 20 april om 13.37 uur had bekeken

Dus ik kan teruggaan in de tijd, en als ik dat eenmaal heb gedaan, zullen alle verschillende tabbladen die we hier zien dat specifieke tijdstip weerspiegelen, inclusief de vragen die mogelijk slecht zijn uitgevoerd, inclusief misschien als Ik heb sessies gehad met blokkeren. Al dat soort dingen zou in de tool verschijnen en het staat me toe om die historische informatie duidelijk te benutten om het probleem op te lossen. Als we het over de geschiedenis hebben, is het andere dat het vermelden waard is dat het niet alleen de geschiedenis gebruikt om problemen op te lossen. Die geschiedenis is uiteraard om andere redenen zeer waardevol. En een van de groten is om efficiënt beslissingen te kunnen nemen en om snel beslissingen te kunnen nemen met de juiste informatie. Dus al die geschiedenis, alle informatie die we verzamelen, kunnen we melden.

Als iemand naar me toekomt en zegt: "Ik heb deze echt geweldige nieuwe applicatie. Het zal de wereld veranderen zoals we die kennen. Oh, trouwens, het vereist een database, en oh trouwens, het gaat echt de koppeling maken I / O op de machine waar die database zich bevindt. " Als ik weet dat ik er op inga, dan kan ik die informatie gebruiken om een ​​rangorde van al mijn productieservers te kunnen bieden, misschien gebaseerd op de laatste zeven dagen van verzameling. En ik zou heel snel kunnen concluderen welke instanties het meest logisch zijn om die database in te zetten. Het is dus dat soort historische informatie dat uiteraard ook zeer waardevol is.

In termen van de vragen zelf; wat betreft het bekijken van de vragen, we hebben veel verschillende manieren om dat in de tool te doen. En ik kijk graag naar de Query Waits View, omdat de Query Waits View erg handig is om te kunnen beoordelen. Als ik een knelpunt heb dat zich voordoet, om in wezen alle verschillende gebieden te kunnen identificeren die van invloed zijn op die specifieke, specifieke zoekopdracht; niet alleen de query zelf en wat de impact van die query is, maar ook, weet je, uit welke applicatie het kwam, uit welke sessie het kwam, welke gebruiker het noemde en al dat soort dingen, ik kan duidelijk zien dat informatie in realtime, maar ik heb ook de mogelijkheid om die gegevens uit het verleden te bekijken. En dat is dus een van de dingen hier, en ik heb een script afgetrapt, maar ik moet wachten tot het een beetje opduikt.

Terwijl we daarop wachten, wil ik - en ik weet dat we weinig tijd hebben, dus ik wilde een beetje praten over het waarschuwen van meldingen als proactief. En als je het hebt over dat soort dingen, zoals ik al zei, omdat het het proactieve deel is, zijn er veel tools die waarschuwen. Het moeilijke gedeelte is geen e-mail verzenden. Het harde deel is niet naar het gebeurtenislogboek schrijven of een SNMP-trap genereren. Het moeilijkste is om te weten wanneer u die waarschuwing op de juiste momenten moet verzenden. En daarmee hoort veel berekeningen, te begrijpen: "Waar gaat het over die specifieke instantie en wat is normaal wat die instantie betreft?"

En dus voor alle metrics die hier zinvol voor zijn, baseren we die metrics. We laten u de basislijn zien, we laten u de drempel zien waarop deze momenteel is ingesteld. En dan nog iets leuks, laten we zeggen, ik heb mijn drempels ingesteld op in dit geval zes en tien alleen voor dit voorbeeld. Zes weken vanaf nu, als ik terugkom op dit exemplaar, kan deze basislijn volledig veranderen, omdat een van de dingen die we doen wanneer we de basislijn berekenen, standaard een voortschrijdende zevendaagse berekening is. Dus het geeft me altijd een up-to-date versie van de baseline. En wat gebeurt er als die basislijn mijn drempels overschrijdt? In dit geval kan ik aanbevelingen zien en waarschuwen die in feite zeggen: "Hé, je hebt een drempel die waarschijnlijk onjuist is ingesteld, specifiek voor waar we de drempel zien en duidelijk waar de basislijn is, ga je waarschijnlijk een waarschuwing krijgen voor iets dat normaal is. "

En dus in plaats van een symptoom te behandelen van iets dat normaal is, kan ik dat soort situaties identificeren waarin de werkelijke drempel onjuist is ingesteld. En wat dat mij duidelijk laat doen, is de drempels instellen in overeenstemming met waar ik een waarschuwing ga krijgen. Ik weet dat het meer een oproep tot actie is dan een onderzoek om te zien of het echt een probleem is. En ik denk dat een deel van de tool echt nuttig is in termen van de basislijn zelf en het kunnen berekenen.

Nu hebt u met dit product de mogelijkheid om daadwerkelijk meerdere basislijnen te hebben; u kunt ze voor verschillende tijdsperioden instellen en u kunt de drempels dynamisch aanpassen op basis van uw basislijnen, wat ook een zeer belangrijk onderdeel is van het soort aanpassing aan de wijzigingen die dagelijks plaatsvinden aan uw SQL Server-exemplaren . Nu, in dit geval hier, behandelen we een aantal van de instellingen van de drempels en laten we u de basislijnen zien. Maar wat de werkelijke meldingen betreft, is de melding zelf, het leuke van Diagnostic Manager, dat deze u meerdere waarschuwingsprofielen biedt. Dus als u bijvoorbeeld een oproepprofiel hebt van 2:00 tot 5:00 uur, dan kan ik een profiel hebben dat specifiek is voor dat tijdsbereik, en ik kan hier alle voorwaarden en de juiste instellingen instellen voor mijn reactie.

Het punt met de reactie is dat ik in sommige gevallen ja een e-mail kan sturen, of dat ik kan schieten en een SNMP-trap kan genereren of naar het gebeurtenislogboek kan schrijven. Er zijn een heleboel andere dingen die we kunnen doen, maar terwijl ik met DBA's praat, is wat ze echt heel leuk vinden het feit dat in de meeste gevallen veel van het werk dat wordt uitgevoerd, repetitief is. Het zijn dingen die ze precies weten wanneer het probleem zich voordoet, wat ze moeten doen om het op te lossen. Ze moeten gewoon ingrijpen. En dus naarmate je je omgeving laat groeien, naarmate je meer instanties hebt, wordt dat een stuk moeilijker om te doen. Dus een van de dingen die je in de tool kunt doen waarvan ik denk dat het vermelden waard is, is dat je wel de mogelijkheid hebt om een ​​voorwaarde in te stellen, maar op basis van die voorwaarde een reactie kunt instellen om een ​​script uit te voeren, een taak, om een ​​uitvoerbaar bestand uit te voeren. En het punt is dat als je besluit om een ​​script uit te voeren, ik binnen dat script parameters kan gebruiken die tijdens de uitvoering worden ingevuld, gevuld met de werkelijke informatie.

Dus als er problemen zijn met een specifieke database, wordt het script ontworpen om alleen te worden uitgevoerd tegen de database waar het probleem zich voordoet. Dus je kunt problemen op een geautomatiseerde manier dynamisch aanpakken, en dan kan ik nog steeds een e-mail ontvangen om terug te komen en me te vertellen dat: "Hé, er was een probleem, maar trouwens, het was opgelost." Het script werd uitgevoerd, en als de DBA weet je het, maar je hoefde niet echt in te grijpen. Nu, op dezelfde opmerking over proactief zijn, hebben we hier uiteraard ook een andere functie, namelijk de functie "Analyseren". En wat dit zal doen, is dat het een regelmatige controle uitvoert, tegen het exemplaar van SQL. En in sommige gevallen zal het een diepere duik doen in termen van wat het zoekt. Dingen zoals hypothetische indexanalyse zullen worden uitgevoerd. Voeg ik een index toe? Verwijder ik een index? En al dat soort dingen zullen duidelijk helpen bij mijn prestaties, maar nogmaals, het gaat allemaal om proactief zijn. Het gaat erom beslissingen te nemen voordat dingen kapot gaan en het beter te laten werken. En in veel gevallen proberen we dat hier echt te doen.

Teruggaan naar Query Waits waar we het eerder over hadden; zoals je kunt zien, is hier een grote piek. Ik heb eerder een script uitgevoerd dat alleen maar wat wachttijd veroorzaakte, en zoals ik al eerder zei, hebben we een echt unieke manier waarop je deze informatie kunt bekijken. Als ik wil zien welke toepassing het was; Ik zie dat het afkomstig was van de NoSQL-applicatie. We kunnen de database zien waaraan deze is gekoppeld, de sessie, de gebruiker en als ik dat wil, kan ik dit ook rangschikken in termen van mijn wachttijden. Dus, ik kan zeggen, van alle wachten die plaatsvonden in dat tijdvenster, welke gebeurden het meest? En als ik zie dat wanneer het het meest is gebeurd, het heel leuke is dat ik in dat wachttype kan boren en ik alle opdrachten kan zien. Als je hier kijkt, deden ze dat wachten gebeuren. En ik kan ook in de eerste plaats zien, welke toepassing het was, die ervoor zorgde dat het wachten gebeurde.

Dus het steekt uit als een zere duim. Ik kan meteen gaan zeggen: "Dit is de applicatie die mijn knelpunt veroorzaakt. Wat was de query die werd uitgevoerd? Welke gebruiker heeft deze uitgevoerd? Welke database heeft het uitgevoerd?" Enzovoort. Dus hopelijk is dat logisch, en het helpt ook om ervoor te zorgen dat je niet de latentie in je omgeving hebt, aangezien het betrekking heeft op je databases. Hopelijk is dit nuttig. Ik ga op dit punt door en geef het terug, en ik denk dat vanaf daar kunnen we verder.

Eric Kavanagh: Natuurlijk. Dus ik denk dat ik het gewoon naar onze experts van de dag gooi. Mark, misschien wil je eerst reageren en een paar vragen stellen. Dan Dez, je kunt meedoen.

Mark Madsen: Ja, bedankt, ik heb er echt van genoten om hiervan iets te kijken. Het is een veel intelligentere monitoring dan ik gewend ben te zien. Ik ben benieuwd naar het beheer van de gegevens hierachter; het beheren van de statistieken die je kunt bijhouden, en weet je, kijk in het bijzonder naar dingen zoals het verschuiven van basislijnen, dat een van mijn pijnpunten voor huisdieren is, met dashboards. Hoe ga je om met die gegevens, en het tweede deel daarvan, weet je, baseline metrics, zoals een soort verschuiving - heb je de mogelijkheid om ook automatisch de drempels te verschuiven, zodat ik niet hoef te teruggaan en drempels handmatig resetten, wanneer een basislijn verschuift?

Bullett Manale: Dat doe je, en dus het leuke is dat je dat kunt beslissen. U kunt beide doen. Ik kan een drempel instellen en er een statische instelling van maken, of ik kan het vakje aanvinken om te zeggen: "Maak er een dynamische drempel van, die zal veranderen als mijn basislijnen veranderen." En ik heb de mogelijkheid en de tool om een ​​standaardvenster in te stellen tijd voor mijn basislijn. Maar als dat nodig is, heb ik misschien een afzonderlijk basislijnvenster, bijvoorbeeld van mijn onderhoudsvenster van 02:00, laten we zeggen tot 05:00, omdat ik mijn CPU, mijn schijven en al het andere, want dat is wanneer we al ons onderhoud doen. Het zou dan automatisch, als ik het had geselecteerd, het automatisch mijn drempels aanpassen om buiten te komen wat normaal is voor die meetwaarden die Ik kies ervoor om dat te doen. Ik zou dat kunnen doen. In principe heb je binnen de tool de mogelijkheid om tijdvensters in te stellen, dat zijn je basislijnvensters, en elk venster kan worden behandeld als een afzonderlijke entiteit, in termen van dynamische baselining aanpassen die kan worden gedaan. En u kunt zoveel vensters van uw basislijn toevoegen als u dat moet, als dat logisch is. Je zou een weekendvenster kunnen hebben, een weekdag tijdens werkuren, een onderhoudsvenster dat midden in de nacht gebeurt, enzovoort enzovoort.

Mark Madsen: bedankt.

Bullett Manale: Ik denk dat we teruggaan naar het eerste deel van de vraag die we hebben en al deze informatie verzamelen. Ik heb niet echt over de architectuur gesproken, maar we hebben wel een back-end repository, dat je volledige controle hebt over het bewaren van die gegevens, maar we hebben ook een service die midden in de nacht draait en gaat al onze basisberekeningen en het neemt die gegevens, verzamelt en slaat er op. En uiteraard hebt u ook tal van rapporten die we kunnen gebruiken om tegen uw basislijnen te rapporteren, voor specifieke statistieken. En u hebt zelfs de mogelijkheid om uw basislijnen van dezelfde server te vergelijken, voor dezelfde waarde voor verschillende perioden. Je kunt zien of er verschillen zijn opgetreden of wat de delta is. Er zijn ook veel van dat soort opties.

Eric Kavanagh: Dez.

Dez Blanchfield: Een snelle vraag die ik voor u heb - er is een breed spectrum van wat deze tool kan doen. Zie je het gebruik ervan nu al in een vroeg ontwikkelingsstadium of is het nog steeds vooral een hulpmiddel voor de productieomgeving? Met andere woorden, krijgen ontwikkelaars toegang en gebruiken ze dit tijdens hun vroege ontwikkeling en testen ze vervolgens de integratiefase? Of wordt het nog steeds overwegend gebruikt in productieomgevingen?

Bullett Manale: Ik zou zeggen dat we het meestal zien in productieomgevingen. Het hangt af van de situaties, maar voor het grootste deel zou ik in de eerste plaats zeggen productie en wij doen - en het is ook, weet je, eerlijk om te vermelden dat we verschillende prijzen hebben voor ontwikkel- en testomgevingen, dus het is een beetje aantrekkelijker. We zien dat mensen het voor die omgevingen gebruiken, maar ik zou zeggen dat als ik je op de een of andere manier een antwoord moest geven, ik zou zeggen dat het voornamelijk productieomgevingen zijn waarin we mensen een investering voor dit product zien doen .

Dez Blanchfield: Tuurlijk, ja en het was interessant om te horen dat je verschillende prijspunten hebt, want er zijn duidelijk verschillende werklasten, en hoe zwaarder de banen zullen zijn waar al het echte werk wordt gedaan. Maar ik zie veel organisaties, vooral in de overheid, en zeker in defensie, waar ontwikkeling nu hetzelfde niveau van investeringen in tools en systemen krijgt als productieomgevingen, omdat ze veel meer vooraf testen. In de verdediging zijn er bijvoorbeeld teams die miljarden tests, honderden miljarden tests op applicaties en systemen en tools uitvoeren, en deze monitoren voordat ze zelfs aan integratietests beginnen, omdat ze ervoor willen zorgen dat er een code is gebouwd en de database het zit eronder. Het gaat om de honderd en een miljoen iteratie of zo, terwijl je in het veld op iemand schiet, gaat het niet "knal".

Bullett Manale: Zeker.

Dez Blanchfield: In mijn ervaring in de old-school database wereld, denkend dat database-omgeving iets is dat net in gegevens achterblijft en sommigen van jullie weten, worden zeer zelden gezien en zeer zelden over gesproken, dus wanneer we nu het punt krijgen waar tools en apps worden ontwikkeld, vooral met analytische platforms, ze zijn nu in onze handsets en onze apparaten. Ziet u klanten het gesprek van databaseprestaties en databasebeheer min of meer in een meer dagelijkse discussie brengen in plaats van alleen maar techneuten? En ik weet dat je eerder hebt gezegd dat je voornamelijk met DBA's praat, maar is er nu een trend waar het in het algemene vocabulaire voorkomt, zie je mensen waar ze deze onderwerpen bespreken, in tegenstelling tot alleen de nerds?

Bullett Manale: Nou, het is moeilijk om te zeggen. Ik bedoel, zoals ik grotendeels heb gezegd, de mensen met wie we te maken hebben in termen van het verkoopproces zijn sowieso bij de beoefenaars, de DBA's. Dus in termen van uw vraag zegt u alleen: "Over het algemeen zijn de mensen binnen de IT-organisatie steeds meer database-bewust?" Ik denk dat de vraag is en ik zou waarschijnlijk zeggen dat het antwoord "ja" is. Ik zie het waarschijnlijk niet zo vaak, gebaseerd op waar ik ben, van dag tot dag, maar ik denk dat als ik uw vraag begrijp, dit mijn antwoord zou zijn, denk ik.

Dez Blanchfield: Ja, dat is goed. Het is waarschijnlijk een beladen vraag, sorry, want uw belangrijkste belangen in uw wereld zijn uiteraard de technische kant van de zaak. Ik ben nieuwsgierig dat ik in mijn dagelijkse activiteiten organisaties dit heel vroeg in het gesprek begin te brengen. Dus als ze het hebben over nieuwe initiatieven, nieuwe projecten, nieuwe werkprogramma's, is een van de dingen die onmiddellijk komen: "Hoe volgen we het op, hoe volgen we het op, hoe gaan we om met problemen als ze zich voordoen, " in tegenstelling tot lanceren, live gaan? "

Bullett Manale: Ik zou zeggen dat -

Dez Blanchfield: Sorry, ga je gang.

Bullett Manale: Ik zou zeggen dat ik een trend zie die ik denk dat ik zou moeten zeggen - weet je, in het verleden had je vaak de volgende keer: "We hadden een probleem en nu hebben we een tool nodig." " En ik denk dat we een beetje meer acceptatie zien rond het hebben van de tool voordat het probleem zich voordoet, als dat logisch is. Dus ik zou zeggen dat dat absoluut normaler wordt, weet je: "Hé, we hebben een monitoringtool nodig, we hebben iets nodig." En mensen zien absoluut de waarde van dit product, omdat zoals je eerder al zei, alleen DBA's toevoegen en nieuwe instanties toevoegen, je hebt iets nodig dat dat beheert. Je hebt iets nodig dat helpt bij het beheer daarvan, en daarom zien we ook veel acceptatie rond dit product, of we hebben het.

Dez Blanchfield: Snelle vraag. Waar moet dit leven? Moet het precies achterin op het LAN, in het datacenter, zo dicht mogelijk bij de database-omgevingen zitten, of is het comfortabel ergens geplaatst, mogelijk in de cloud, een externe cloud met een soort van hetzij VPN-tunnel of externe toegang tot verschillende omgevingen? Waar moet dat zitten, wat betreft omgevingen en monitoring?

Bullett Manale: Qua architectuur is er een back-end repository en dat is een SQL Server-database. We hebben de console die een fat client of een thin client kan zijn; wij geven u de optie van beide. En we hebben ook een thin client die echt specifiek op mobiele apparaten is afgestemd. Maar in termen van waar dit eigenlijk kan zitten; het kan in een omgeving zitten, eigenlijk is het moeilijkere deel ervan, van veel van de informatie die we moeten verzamelen, vereist het in sommige gevallen of in veel gevallen administratieve rechten. Nu laten we u dat niet doen; als je wilt, kun je gegevens verzamelen en alleen voor de dingen die we niet kunnen verzamelen, omdat we geen beheerdersrechten hebben, laten we je die informatie gewoon niet zien, als dat de keuze is die je maakt.

Afhankelijk van de smaak, zoals als je het over AWS hebt, in sommige omgevingen, werkt het beter dan in andere, maar voor zover het de werkelijke omgeving zelf betreft, is het meestal nodig om SA-authenticatie te gebruiken om de gegevens tegen de instanties te verzamelen. Of als het een niet-vertrouwd domein is, is dat meestal wanneer u dat wilt doen, maar meerdere domeinen; zolang er een vertrouwensrelatie tussen hen is, kunnen we daartegen verzamelen. Het maakt niet echt uit of het zich op een LAN bevindt of op het WAN, de feitelijke verzameling zelf is behoorlijk te verwaarlozen in termen van de hoeveelheid gegevens die we verzamelen. Als we voldoende WAN-verbinding hebben, is dit geen probleem. Ik heb omgevingen gezien waar ze filialen hebben waar ze SQL-servers over de hele Verenigde Staten hebben. En het is één server op elk van die verschillende locaties, en ze monitoren het centraal. Het lastige deel is gewoon ervoor zorgen dat je een behoorlijke hoeveelheid connectiviteit hebt om dat te doen. Hopelijk beantwoordt dat je vraag, het was eigenlijk overal op de kaart.

Dez Blanchfield: Absoluut. Dank je. Dus, twee snelle vragen die vanmorgen door bezoekers zijn binnengekomen; één is: wat is de impact van - vaak zien we dat systeembewakingshulpmiddelen zelf laden genereren door alleen dingen te monitoren, dus de vraag was, sorry het rolde nu van mijn scherm, maar om het gewoon te parafraseren; genereren we zelf monitoring? Is er een meetbare impact van de tool, alleen het kijken naar het milieu, of is het een verwaarloosbare impact?

Bullett Manale: Er zal altijd een beetje impact zijn omdat het de SQL Server-instantie moet opvragen om de gegevens terug te halen. De vraag zoals u zei is: "Is het te verwaarlozen of is het significant?" Als je uit de doos naar een instantie verwijst, is deze te verwaarlozen. We doen dit al een tijdje, zoals ik al zei. We hebben meer dan 20.000 klanten en ik kan u verzekeren dat als het een aanzienlijke invloed op de prestaties heeft, we niet in zaken zouden zijn. Dat gezegd hebbende, stellen we de gebruiker ook in staat om te beslissen wat hij wil monitoren. Dus ik denk dat het belangrijk is om te vermelden dat elke omgeving een beetje anders is.

Een voorbeeld is, met de component voor het monitoren van zoekopdrachten, een van de dingen die we kunnen doen, is dat we de drempel kunnen instellen voor wat u als uw normgrens beschouwt. Dus het kan gebaseerd zijn op het tijdstip van de uitvoering van de query. Het kan gebaseerd zijn op de CPU, I / O, maar laten we als voorbeeld zeggen dat ik mijn uitvoeringstijd op nul milliseconden heb ingesteld. Wat ik de tool eigenlijk vertel, is om alle vragen te verzamelen die zijn uitgevoerd sinds het laatste trekinterval, en dat deel van mijn historische verzameling ook te maken.

Als we dat doen, gaan we het aantal vragen verzamelen dat we sinds de laatste peiling op de doos hadden staan. Nu is dat keuzevrij, en de gebruiker heeft de mogelijkheid om dat te doen. Zeggen we: "Dat is wat u moet doen?" Nee. Maar we geven u ook de optie om dat te doen in het geval u een steekproef van gegevens wilt waarmee u die informatie kunt verzamelen. Dus in het algemeen hebt u de middelen om tool om het in te stellen en af ​​te stemmen zoals u het wilt, op basis van waar u vertrouwd mee bent. Maar u kunt het echt openen als u dat wilt, en veel extra informatie verzamelen die u niet noodzakelijkerwijs regelmatig hoeft te vinden verzamelen, als dat logisch is.

Dez Blanchfield: Ja, absoluut. Ik weet dat we een beetje lang lopen, maar er zijn twee echt geweldige vragen die ik je wil stellen voordat ik afrond. Ze komen allebei rechtstreeks naar me toe, maar ik denk dat het het beste is als je ze beantwoordt. De vraag was in het algemeen: "Wat is de reikwijdte van het bereik van de tool voor zover kennis van bestaande systemen?" Dus kunnen we dit gewoon aansluiten en het automatisch het aanwezige platform laten detecteren en weten wat normaal is voor dat platform, en onmiddellijk waar Mark eerder over sprak? Een deel van de basiskennis van de platforms door, weet je, ik weet het niet, het kan Microsoft Dynamics zijn. Wat is de reikwijdte van de kennis van het platform met wat normaal is en in sommige van de huidige off-the-shelf tools die worden gebruikt in het bedrijfsleven?

Bullett Manale: Ik zou zeggen dat we in het algemeen, wanneer we beginnen met het verzamelen van gegevens over de SQL-instantie, werken met best practices om te beginnen, in termen van onze drempels en waar ze zijn ingesteld. Dat gezegd hebbende, erkennen we ook dat met wie je ook praat, elke omgeving anders is. Wat we in eerste instantie doen, verzamelen we alleen de gegevens, en wat we mensen aanbevelen, kunt u het product 14 dagen langer proberen als dat nodig is. Maar na ongeveer twee dagen zult u de basislijngegevens zien verschijnen. Zodra het voldoende voorbeeldinformatie heeft om mee te werken, begint het u de context te geven in termen van de basislijn, waar het bereik is, en al dat soort dingen. Daarna kunt u, als u dat wilt, automatisch uw drempels instellen op basis van de verzamelde informatie. Er is een klein beetje initiële verzameling en polling nodig om te kunnen bepalen wat normaal is, zodat je je drempels kunt gaan verleggen.

Maar wat ik denk dat ook het vermelden waard is, is dat wanneer je die drempels wijzigt, dit kan worden gedaan op een groep per groep basis van je instanties. Het kan specifiek zijn voor één instantie of u kunt het doen tegen al uw instanties, evenals de mogelijkheid om dingen zoals sjablonen te maken, zodat u kunt zeggen: "Dit is een productie-instantie, maar dit is de sjabloon die ik wil toe te wijzen. " En dus wanneer een nieuw productie-exemplaar online komt, passen we die drempels automatisch toe, omdat het hetzelfde type hardware heeft en meestal dezelfde werklasten heeft, dus we zouden het ook op die manier kunnen doen. Hopelijk helpt dat bij de vraag.

Dez Blanchfield: Absoluut. In feite heb je eigenlijk een andere vraag beantwoord die net bij mij binnenkwam, en die was: "Is er een proefdownload?" Er is, ik kan dat beantwoorden, ik weet het. Ik weet zeker dat je zult bevestigen dat er een gratis download is en ik denk dat je zei dat het 14 dagen van de website was. Je kunt het downloaden en ermee spelen. Maar ik denk dat dat snel is: "Wat voor omgeving heb ik nodig om de proef te kunnen uitvoeren? Kan ik het op mijn laptop gebruiken en ermee spelen of heb ik echt een server nodig?"

Bullett Manale: Het belangrijkste dat het nodig heeft is een repository, een SQL Server-database die 2005 of hoger is. Anders dan dat, zijn er enkele minimale bronvereisten, een .NET-vereiste, en dat is alles. Het is dus gewoon een kwestie van het product installeren en een database maken.

Dez Blanchfield: Perfect. Een laatste vraag die ik je zal stellen, want we hebben nu gewoon geen tijd meer, maar al snel vroegen ongeveer twee of drie mensen me: "Moet ik een DBA zijn om daadwerkelijk aan de slag te kunnen met dit, en ermee spelen? '

Bullett Manale: Nee. Ik zou zeggen dat als je een DBA bent, je de tool op verschillende manieren zult gebruiken. Ik bedoel, er zal waarschijnlijk een beetje meer waarde zijn als je een ervaren DBA bent. Je gaat veel meer diepgang zien in de tool waar je van kunt profiteren. Maar ook als een nieuwe DBA, of zelfs een persoon die, dat is geen DBA, we hebben veel aanbevelingen, en ik ben nu op die pagina. Deze aanbevelingen zullen regelmatig verschijnen en het leuke van de aanbevelingen is dat ze je de redenen geven waarom de aanbevelingen worden gedaan. Maar daarnaast hebben ze ook links naar externe inhoud die gedetailleerder beschrijven over de redenen waarom die aanbevelingen ook worden gedaan. Dus dat zal linken naar externe Microsoft-websites, blogs en allerlei andere dingen, dat is extern.

Maar om je vraag te beantwoorden, het is een beetje, weet je, als je een senior DBA bent, zullen hier dingen zijn waar je waarschijnlijk van zult profiteren, die je waarschijnlijk niet als een beginnende DBA zou zijn. Maar tegelijkertijd is het ook een soort leermiddel, want als je deze aanbevelingen doorloopt, zul je sommige van deze dingen zelf gaan oppakken door de aanbevelingen te gebruiken.

Dez Blanchfield: Fantastisch. Dank je. Ik heb echt genoten van het demo-gedeelte. De presentatie was geweldig. De demo was fantastisch. Snel uit het geheugen, er is een heel bronnencentrum op je website dat ik mensen aanraad om ook eens te bekijken. Ik herinner me dat ik die afgelopen nacht heb doorgenomen om wat details te krijgen. Je hebt een hele reeks dingen, alleen van je blogs en gegevens en gesprekken tot, vanuit het geheugen, je hebt het grootste deel van je productdocumentatie ook online, ja?

Bullett Manale: Ja, dat klopt, en de vorm waarvan ik denk dat je hiernaar verwijst, is de website community.idera.com. En dan één ding dat ik ook zou noemen, waar je eerder naar vroeg: "Gaat het de omgeving herkennen?" In termen van nieuwe instanties of het toevoegen van instanties, is er een andere tool die we gebruiken om instanties te ontdekken. En het draait allemaal om inventaris en het beheren van uw inventaris. Ik zou je gewoon een beetje in die richting willen wijzen, in termen van het daadwerkelijk ontdekken van de instanties. Maar wat betreft de prestaties en monitoring, al dat soort dingen waar we het over hadden gehad, dat is waar de Diagnostic Manager van pas zou komen.

Dez Blanchfield: Fantastisch. Kijk, geweldige dekking. Echt genoten van je presentatie. Ik was dol op de live demo en dat is allemaal van mij vanmorgen, want ik weet dat we waarschijnlijk 10 minuten over tijd zijn gegaan. Eric, ik ga terug naar jou.

Eric Kavanagh: Oké. Ik hield gewoon van de demo. Ik ben blij dat je de demo hebt gedaan. Ik ben blij dat we daar goed naar hebben kunnen kijken tijdens de Q&A.

Bullett Manale: Geweldig.

Eric Kavanagh: Omdat dit mensen een idee geeft van waar je naar kijkt, en het verbaast me echt een beetje om te denken dat we nog steeds aan het leren zijn over hoe we met deze computers moeten praten, als je er meteen achter komt. Ik bedoel, dit niveau van diagnostiek is behoorlijk geavanceerd en het wordt elke dag beter. We krijgen veel meer inzicht in wat er feitelijk gebeurt. Maar je hebt echt iemand nodig die dit spul overziet, het leest, dat cognitieve vermogen achterlegt aan wat je doet, toch?

Bullett Manale: Ja, ik bedoel in veel gevallen - ik wou dat ik je kon vertellen dat dit een DBA in de doos is, maar er zijn gewoon teveel dingen aan de hand. Ik bedoel, we geven begeleiding en we helpen wel, maar uiteindelijk moeten mensen beslissingen nemen over de gegevens die we presenteren. Ik denk niet dat dat binnenkort zal veranderen.

Eric Kavanagh: Nou, dat is goed nieuws voor de echte mensen daar, mensen.

Bullett Manale: Dat klopt.

Eric Kavanagh: Je wilt dat iemand dit bekijkt, een team dat dit bekijkt, en je zult leren, zoals je van Bullett hier hebt gehoord, naar deze aanbevelingen kijken en gaan oppikken wat er aan de hand is. En ik gok op basis van die geschiedenis, en ik denk dat je dit hebt aangeraakt, Bullett, maar heel snel, die geschiedenis stelt je in staat om belangrijke patronen te herkennen en ze daarom te kunnen identificeren wanneer ze in de toekomst gebeuren, toch?

Bullett Manale: Dat klopt. Een van de dingen die we kunnen doen, is de prestaties van een zoekopdracht in de loop van de tijd bijhouden. We kunnen natuurlijk ook naar andere dingen kijken, zoals basislijnen en ze zien verschuiven, en uiteraard meldingen en dergelijke krijgen als dat gebeurt, dus je hebt die mogelijkheid zeker.

Eric Kavanagh: Dat klinkt goed, mensen. We zouden hier niet lang geweest zijn, maar ik wilde op die vragen ingaan. Heel erg bedankt voor je tijd en aandacht. We archiveren al deze webcasts. Spring online naar Techopedia.com of naar InsideAnalysis.com, je ziet links van beide plaatsen.

En daarmee zeggen we u vaarwel. Nogmaals bedankt, mensen, we zullen je volgende week weer inhalen, volgende week, dinsdag, woensdag en donderdag nog drie webcasts. Dus we spreken je volgende week, mensen. Wees voorzichtig. Tot ziens.

Techopedia Content Partner

Techopedia Staff is aangesloten bij Bloor Group en kan worden gecontacteerd met behulp van de opties aan de rechterkant. Klik hier voor informatie over hoe we samenwerken met partners uit de industrie.

• Profiel
• Website