Spettacolo teatrale: saluta la latenza

Di Techopedia Staff, 9 maggio 2016

Takeaway: il conduttore Eric Kavanagh intervista Mark Madsen, Dez Blanchfield e Bullett Manale su latenza ed esibizione.

Al momento non sei collegato. Accedi o registrati per vedere il video.

Partner di contenuti Techopedia

Lo staff di Techopedia è affiliato a Bloor Group e può essere contattato utilizzando le opzioni sulla destra. Per informazioni su come lavoriamo con i partner del settore clicca qui.

• Profilo
• Sito web

Eric Kavanagh: signore e signori, ciao e bentornati di nuovo a Hot Technologies! si Certamente. Mi chiamo Eric Kavanagh, questo è il nostro spettacolo Hot Tech, una partnership con i nostri buoni amici di Techopedia. Passa online a Techopedia.com per tutte le ultime novità nel vasto campo della tecnologia aziendale; ovviamente coprono anche le cose dei consumatori. Ci concentriamo sull'impresa qui sul nostro programma, quindi è quello che faremo oggi.

C'è un posto nel tuo davvero e abbastanza su di me, colpiscimi su Twitter @eric_kavanagh, adoro Twitter, adoro dare un'occhiata a queste cose, è un ottimo modo per rimanere in contatto con le persone e avere buone conversazioni e one-on -una conversazione.

Allora, di cosa stiamo parlando? Quest'anno è caldo, questo è un intero universo di opportunità che guardiamo oggi nel mondo della gestione delle informazioni, e ciò di cui stiamo parlando oggi saranno query, accelererà le query.

Penso di aver dimenticato di menzionare il titolo "Performance Play: dire addio alla latenza". Bene, chi vuole la latenza? Nessuno vuole la latenza, la latenza è quando ti siedi lì, fai clic sul pulsante e attendi che accada qualcosa, e nessuno lo vuole. Ai bambini non piace, non pensano che sia bello, nemmeno agli adulti. Siamo stati tutti viziati dalla velocità del web e vogliamo le cose rapidamente, le vogliamo ora e ne parleremo oggi nel nostro show.

L'analista Mark Madsen è con noi oggi da Third Nature, uno dei nostri clienti abituali. Il nostro nuovo scienziato di dati, Dez Blanchfield, chiama da Sydney, in Australia. E poi Bullett Manale, sì davvero, questo è il suo nome, in realtà dovrebbe essere due T. Bullett Manale è il nostro ospite di Idera, un'azienda molto, molto interessante, che fa molte cose. Li conosco già, uno dei quali hanno acquistato una società chiamata Precise qualche tempo fa. Conoscevo il loro CEO di nome Zohar Gilad, come va per un nome? Era un diavolo di un ragazzo intelligente.

Ma gente, svolgi un ruolo significativo in questo webcast nelle domande che fai, quindi per favore non essere timido, invia le tue domande in qualsiasi momento - potresti farlo usando il componente Domande e risposte della console del webcast, che è laggiù nell'angolo in basso a destra. Puoi anche chattare con me e lo chatterò con gli altoparlanti. Abbiamo già qualcuno che chiama dall'Italia, quindi, “Ciao, ciao. Come stai? ”Va bene, con quello spingerò la prima linea di Mark, consegnerò il mazzo a Mark. Mark, ora hai il WebEx. Portalo via, il pavimento è tuo.

Mark Madsen: Grazie, Eric. Non ho intenzione di iniziare nel mezzo, inizierò all'inizio. Quindi solo alcuni commenti per avviare la discussione con Dez e Idera, una sorta di stato con sviluppo e database e operazioni. E sai, se guardi questo, abbiamo ancora questo tipo di problemi a due mondi nel database e nel mercato delle applicazioni, perché gli sviluppatori vedono i DBA come le persone che li infastidiscono. Devi costruire modelli di dati, non puoi accedervi, non puoi creare quella cosa, non puoi mettere un indice su ogni colonna di ogni tabella del database per renderlo più veloce. E, naturalmente, perché abbiamo bisogno dei modelli? Sono solo strutture di dati, se le cambiamo, non puoi semplicemente scriverle in un modulo serializzato?

Il problema è che gli sviluppatori conoscono il codice e le applicazioni, ma due cose che spesso non conoscono sono la concorrenza, la programmazione concorrente, i database e i sistemi operativi sottostanti. Essendo stato uno sviluppatore del kernel e sistemi operativi e database, posso dire che la concorrenza e il parallelismo sono davvero difficili, e così molte cose che impari per ottenere buone prestazioni dal tuo codice, iniziano davvero a cadere quando stai lavorare con un database. E le prestazioni sembrano eccezionali, l'ambiente di test è eccezionale e l'ambiente di domande e risposte, quindi colpisce il sistema reale e all'improvviso non è poi così eccezionale. Perché ha molte sfaccettature, come funziona il codice con il database, come funziona con l'ambiente e piccole pratiche davvero semplici possono avere effetti drastici a seconda della scala in esecuzione.

E quando inizi a parlare di applicazioni esterne, ovviamente, le applicazioni rivolte verso l'esterno, le applicazioni web, possono essere davvero difficili perché le cose vanno benissimo fino a quando all'improvviso diventano piatte e non lo sono. Colpirai questi altopiani interessanti che richiedono molta sfumatura per capire.

Il rovescio della medaglia è la vista DBA. La visione DBA è che ci sono operazioni, che trascorrono gran parte del loro tempo, dall'80 al 90 percento, in operazioni operative e forse dal 10 al 20 percento che si occupano delle cose di sviluppo che stanno andando avanti. Da questo punto di vista, o paghi ora o paghi in seguito, e se trascorri tutto il tuo tempo in anticipo, avrai più probabilità in seguito, a differenza dello sviluppo che tende ad esplorare una funzione spazio e cercando di capire come fare al meglio le cose. E quindi abbiamo problemi, e ora abbiamo metodologie incompatibili: distribuzione continua, rollup delle tue app ogni volta che sono pronte, invio periodico di codice, lavoro in un negozio che sta praticando attività. Questo genere di cose accelera lo sviluppo, ma tutte le pratiche relative al database e ciò che fanno i DBA e ciò che i gestori di sistema sono stati addestrati a fare, le pratiche delle operazioni IT non hanno tenuto il passo.

Se ci pensate, la maggior parte dei DBA opera in un ambiente di controllo delle modifiche rispetto a un ambiente di distribuzione continua. Si tratta di stabilità e controllo, rispetto alla velocità di cambiamento e reversibilità. Implementazione continua, se non riesci a uscire dal cambiamento, sei nei guai, quindi tutto deve essere costruito per essere facilmente reversibile e commutabile in codice, il che non è molto il modo in cui il database relazionale, le pratiche di sviluppo e le pratiche di gestione hanno funzionato .

Ti stai anche imbattendo in questi problemi di dover essere più proattivo se puoi, come DBA, perché quando senti un problema, centinaia di migliaia di persone stanno compilando moduli di reclamo sul tuo sito web. Ciò ti lascia aver bisogno di alcune cose nuove che non esci dal tuo vecchio ambiente. Sai, cose come un migliore monitoraggio e allerta. Allo stesso tempo, i database si sono moltiplicati, abbiamo ottenuto più applicazioni che mai per supportare più cose che mai, sono dentro, sono fuori, sono ovunque. E più set indipendenti di dati per le analisi, le persone stanno avviando database dappertutto perché, ovviamente, ora è facile, è possibile configurare una macchina virtuale. Se hai un provider cloud o un cloud interno, puoi immediatamente far apparire le cose e questo cambia l'intero percorso di approvvigionamento.

Il vecchio percorso di approvvigionamento era: "Ho tempo per ottenere un server, inserirlo in un rack, allocare spazio, ottenere spazio di archiviazione, installare il database e fare le cose", rispetto a qualcuno che passa una carta di credito e va in cinque minuti. Se lo fai, quel moderno ambiente di sviluppo sta funzionando a un ritmo molto diverso, quindi è facile creare database e questo crea questo problema di proliferazione, come mai abbiamo visto prima. E questo è successo da dieci anni, questa non è una novità per nessuno, ma significa anche che gli ambienti operativi sono cresciuti in complessità.

L'intero ambiente del server client è davvero cambiato, perché non è più un mondo di server client. Allora avevi un server, avevi un database, se qualcosa non andava sapevi a quale server andare, sapevi come gestire le risorse su di esso perché la migliore pratica era un database, un server. La virtualizzazione ha iniziato a spezzarlo, il cloud lo spezza ancora di più, perché quello che pensi sia un server di database, è solo un software. Quindi l'ambiente non è reale. È ciò che contiene l'ambiente che è la realtà, e che potrebbe essere un rack di blade o un grande server fatto a pezzi, non lo sai davvero.

Tutto ciò che riguarda l'amministrazione del database e la gestione delle prestazioni, e quali database sono stati costruiti attorno al controllo stretto con un server, o una manciata di server e un paio di database, non puoi controllare tutto. Sei seduto su una macchina, ma la larghezza di banda non può essere facilmente partizionata dai gestori virtuali, quindi tutto può andare bene con memoria e CPU, ma hai il collo di bottiglia su alcune risorse che non possono essere gestite, e poi quando si tenta di risolverlo, il vecchio modello sarebbe stato un duro lavoro, ottenere un server più grande e fare qualcosa del genere, ora potrebbe essere davvero semplice, basta aggiungere un corso virtuale, solo aggiungere memoria alla VM ed è risolto. Ma cosa succede se la VM si trova su un server sovraffollato e deve migrare? O cosa succede se hai le dimensioni di un sistema AWS e la dimensione massima è stata raggiunta, ora dove vai?

Quindi hai tutti questi problemi in cui l'ambiente fa parte del database ora, impacchetti un ambiente con un database, tutte le risorse speciali, tutto nell'applicazione fa parte della configurazione, la configurazione viene trasferita lì. Questo proviene dall'ambiente del database, è molto più difficile da gestire e controllare.

Se guardi cosa hanno fatto i centri database, sono rimasti seduti per mano, giusto? Ci siamo allontanati da questa idea di trattare database e server come animali domestici. I server hanno nomi, li trattate come se fossero cose singolarmente uniche, le trattate come bestiame, gestisce una mandria. E il problema con la gestione delle mandrie è che se non le controlli, alla fine possono precipitarsi e una precipitosa non è una buona cosa. Abbiamo bisogno di migliori strumenti di monitoraggio, abbiamo bisogno di modi migliori per gestire queste cose e sapere cosa è stato interessato. Nel vecchio modello era più facile perché le tue operazioni e tutti i tuoi sistemi di controllo ti dicevano, ma quando il nome del tuo server è un codice UPC, è un po 'difficile capire le cose.

Non puoi permetterti falsi allarmi, non puoi permetterti cose che dicono: "C'è un problema con questa macchina e quella macchina ospita 30 database". Non puoi permetterti di avere cose che non ti danno cronologia. Le console di monitoraggio sono fantastiche quando si accendono, ma se la luce rossa diventa di nuovo verde e non sai perché, e non hai alcuna storia in cui tornare a guardare cosa stava conducendo a quello e cosa contesto era, sei nei guai. Abbiamo bisogno di sistemi che monitorino per noi, abbiamo bisogno di un migliore monitoraggio, affrontando i problemi intermittenti che mantengono la cronologia dei dati.

Cose migliori e soglie di metriche semplici che ci forniscono metriche chiave, ma non ci guidano direttamente in ciò che è normale, ciò che è anormale e con quale frequenza si verificano questi problemi. Ciò di cui stiamo davvero parlando è una combinazione di monitoraggio dell'ambiente e gestione delle prestazioni, e i venditori sono rimasti seduti per mano. Non ci hanno dato strumenti migliori. Abbiamo sistemi con più CPU e memoria di quanto sappiamo cosa fare con tutto ciò, eppure facciamo ancora affidamento su modelli di intervento manuale, non abbiamo messo la macchina al lavoro, per guidarci, per portarci al punto di problemi, non siamo arrivati ​​a questo nuovo stile che è "C'è un problema qui, puoi farlo per risolverlo" o "C'è un problema di prestazioni, in realtà è con questa specifica istruzione SQL, qui ci sono tre cose che potresti utilizzare per correggere tale istruzione SQL. ”Applicazione dell'euristica, applicazione di modelli di apprendimento automatico in grado di esaminare i modelli di utilizzo del sistema per individuare i problemi ed evitare falsi avvisi. Usare la macchina per fare ciò che la macchina fa meglio, per aumentare il DBA o per aumentare la persona che deve affrontare i problemi di prestazioni.

Questo è il nuovo modo, al contrario del vecchio stile. C'è un problema con questo database, le cose sono lente e quindi abbiamo nuove tecniche, nuovi modi per farlo, e dovremmo applicarle, ed è qui che sta andando il mercato. Stai vedendo che inizia a crescere, non con i grandi fornitori, ma con aziende di terze parti, e questo rispecchia qualcosa che è successo 20 anni fa quando i fornitori di database non hanno fornito una sola cosa per aiutare a gestire i sistemi. Quindi è in qualche modo la direzione del mercato, e con ciò vorrei tornare a Eric.

Eric Kavanagh: Bene, lo consegnerò a Dez. E Dez, portalo via, il pavimento è tuo.

Dez Blanchfield: Grazie, Mark. Hai fatto un ottimo lavoro nel coprirne il componente tecnico. Ci proverò da una prospettiva leggermente diversa per evidenziare cosa è successo nel resto del mondo, per quanto riguarda l'impatto sulle aziende e sui database che li circondano. Vorrei solo saltare alla mia prima diapositiva.

Sul retro di ciò che hai appena coperto dal lato tecnico delle cose e dal lato degli sviluppatori, sto vedendo le aziende che devono affrontare la sfida dei dati e dei database in particolare, e ovviamente abbiamo avuto questo significativo spostamento verso questo concetto di big data, ma i database in realtà sono ancora il cuore e l'anima di dove le organizzazioni conservano le loro informazioni commerciali, ed è dalla porta principale fino al back office. Ogni parte dell'organizzazione è toccata da un database di qualche tipo e alimentata da un database, e molto raramente vado in discussioni di progetto o in qualche forma di conversazione strategica innovativa in un'organizzazione in cui l'argomento del database o del sistema di database non si presenta, e ci sono sempre domande sui tipi di cose di cui abbiamo appena sentito parlare, in termini di prestazioni e sicurezza e su come lo sviluppo viene affrontato da questa sfida, dove si adattano i database e la nostra conoscenza degli ambienti e dell'applicazione ambienti con cui parlare, che dire di dispositivi e mobilità?

È ancora un argomento molto, molto caldo, ed è stato uno per molto, molto tempo nel grande schema delle cose per quanto riguarda la tecnologia moderna. A quel punto, credo sia un dato di fatto che quasi tutto ciò che facciamo nelle nostre vite quotidiane, cioè nelle nostre vite quotidiane, che è ora supportato da una qualche forma di database. Quando pensiamo a tutto ciò che ci circonda, sia che si tratti di una fattura che arriva quotidianamente per posta per un servizio che stiamo acquistando, viene inevitabilmente stampato da un sistema che sta parlando con un database e ci siamo. I nostri telefoni dispongono di database su di essi con i contatti, i registri delle chiamate e altre cose.

Ovunque andiamo, c'è una qualche forma di database dietro il discorso e i sistemi che stiamo usando, e il più delle volte, sono abbastanza trasparenti per noi, ma il fatto è che sono lì. Quindi ho pensato di capire rapidamente perché questo è diventato un po 'un problema in un periodo di tempo molto breve. All'inizio, il concetto di database proveniva da questo adorabile gentiluomo, Edgar Codd. Mentre lavorava in IBM, ha cambiato il mondo per quanto riguarda la gestione dei dati creando un concetto che ora chiamiamo database relazionale.

All'inizio, il database era un database e la vita era buona, era abbastanza semplice sia nelle colonne, sia nei riferimenti, e così via, e nelle tabelle, e lo sviluppo del software era piuttosto semplice e le prestazioni non erano un grosso problema - era una nuova entusiasmante tecnologia. Abbiamo accesso ai database attraverso una qualche forma di terminale, e puoi davvero creare così tanto caos alla fine di un terminale 3270 su un mainframe, e invariabilmente altri tipi di terminali, arrivavano quegli altri sistemi. E nella maggior parte dei casi, i terminali vecchio stile erano molto simili a quelli che sono gli ambienti web ora, e cioè che riempiresti un modulo sullo schermo sul terminale stesso e premi Invio e il gioco andrebbe, sarebbe sparare come un pacchetto, come una richiesta, e il sistema back-end lo gestirà. Questo è essenzialmente ciò che accade in un browser Web in questi giorni, quando si digita un collegamento in un browser Web e quel modulo di solito non torna in tempo reale al sistema, anche se in questi giorni AJAX non è del tutto Astuccio.

Ma poi è successo qualcosa, il futuro è arrivato, e più recentemente Internet, e quasi ieri, in un secondo web 2.0, e proprio dietro l'angolo abbiamo l'Internet of Things. E nel processo del futuro che sta accadendo, il mondo del database è appena esploso e le interazioni con i database sono appena diventate una cosa che tutti abbiamo fatto di default, non è un caso che tu vada da qualche parte per fare qualcosa, come comprare un biglietto per un aereo, e vuoi viaggiare dall'altra parte del pianeta, qualcuno ha dovuto digitare nel terminale tutti i tuoi dati e andare in un database e stampare un biglietto.

Quasi tutto ciò che facciamo ora, sia che stia chiamando un taxi su Google con un'applicazione, sia che stia saltando su internet banking, tutto ciò che facciamo quotidianamente, con una sorta di sistema, è alimentato da un database. E quando è arrivata Internet, è stato un po 'più facile portarci, le nostre vite quotidiane attraverso un browser Web, e poi è arrivato il Web 2.0 e le cose sono diventate mobili e la scala delle cose è semplicemente esplosa. In effetti, la mia linea preferita in questo argomento è che "Internet ha collegato tutto, il web 2.0 lo ha reso mobile e sociale, e le cose sono diventate molto, molto grandi e ora abbiamo Internet e le cose e, e l'IoT … Yikes !!" Non abbiamo nemmeno iniziato a immaginare l'impatto dell'Internet of Things quando si parla al mondo di sistemi di database.

Quindi, in termini moderni, quello che eravamo abituati a considerare un terminale è diventato effettivamente queste cose, sono telefoni cellulari, sono vari tipi di tablet, sia tablet di grandi dimensioni per uso personale o aziendale, sono laptop ed è il desktop tradizionale in qualche forma. In quell'immagine puoi vedere quasi tutte le forme di interfaccia che ora stiamo usando per parlare con i sistemi di database e le app che sono alimentati da quelli, dai piccoli gadget nelle nostre mani che camminano e sembra che siamo incollati, tutto il passaggio alle versioni leggermente più grandi, e agli iPad, e altri tablet e Microsoft Surface, ai laptop di tutti i giorni, che sono inevitabilmente il caso degli ambienti professionali e così via. Le persone tendono ad avere un laptop e non un desktop fisso, ma sono il terminale moderno secondo me e parte del motivo per cui i database stanno affrontando tutti i tipi di sfide nella parte delle prestazioni di gestione della nostra vita, e non solo lo sviluppo.

Quindi presumo che sia una delle maggiori sfide che le aziende devono ancora affrontare quotidianamente. Tutti pensavano che i database fossero i nostri unici problemi, non lo sono. Allora, di cosa si tratta? Bene, quando passiamo da un'estremità all'altra con tutte le cose relative ai database, dal punto di vista commerciale, e Mark ha trattato molto bene i componenti tecnici, ma in senso commerciale, come organizzazione, pensiamo ai database. Abbiamo a che fare con le cose dal design di base e dallo sviluppo front-end. Quando un'azienda inizia, penserà allo sviluppo di applicazioni, allo sviluppo di una capacità o persino all'implementazione di un'applicazione esistente in qualche modo. Deve aver luogo una qualche forma di progettazione e sviluppo e si deve riflettere su come questi sistemi di database verranno implementati, supportati e gestiti, e le prestazioni monitorate e così via.

L'integrazione dell'ambiente di database e delle applicazioni, nonché i tipi di API, i tipi di accesso forniti ora stanno diventando sempre più stimolanti, più complessi. Amministrazione quotidiana, supporto e backup, ancora una volta, queste sono cose che pensavamo fossero risolte, ma all'improvviso la scala è diventata molto più grande e le cose si sono mosse più velocemente e il volume è molto più grande; la dimensione degli ambienti, i sistemi di database dovevano supportare la velocità con cui si muovono le transazioni.

Pensa a un database in un ambiente di trading ad altissima frequenza, non c'è modo in cui gli esseri umani possano tenerne traccia, è solo un gruppo di macchine che combattono un altro gruppo di macchine per fare trading, acquisti e vendite ad alta frequenza, e il volume a che tali transazioni avvengono. Pensa a uno scenario moderno, come un'uscita anticipata di un film Netflix in cui non stai parlando solo di centinaia o migliaia, o addirittura di centinaia di migliaia, potenzialmente milioni di persone che vogliono vedere quel film dal momento in cui è stato rilasciato. Tutte queste informazioni vengono acquisite, tracciate, registrate e analizzate in una piattaforma di database.

E poi c'è il mondo sempre attivo in cui viviamo ora, 24 ore su 24, 7 giorni su 7, non solo per seguire il Sole ma c'è sempre qualcuno a mezzanotte che vuole fare qualcosa, e gli orari di lavoro seguono il Sole in tutto il mondo. Quindi il tempo di attività e la disponibilità sono predefiniti, sono un clima ora, avere un'interruzione in realtà non è una cosa accettabile. E la ridondanza, se c'è un problema di prestazioni o se abbiamo bisogno di una finestra di manutenzione per fare un aggiornamento o una patch, o una sicurezza, davvero, dobbiamo essere in grado di tagliare da un ambiente di database a un altro e farlo senza problemi e automaticamente.

Sicurezza, standard e conformità, negli ultimi tempi sono successe cose piuttosto importanti, in particolare GFC, quindi abbiamo una serie di nuove sfide da affrontare in merito a conformità, sicurezza e standard di corrispondenza, e abbiamo bisogno per essere in grado di riferire su quelli in tempo reale e idealmente in una dashboard. Non vogliamo inviare una squadra di scimmie a un data center che cerca di trovare cose, abbiamo bisogno che il sistema lo dica immediatamente, in tempo reale.

E i due grandi e divertenti di cui quasi nessuno parla mai, li spingiamo generalmente sotto il tappeto e speriamo che non alzino mai la testa brutta, ma il disastro e la continuità aziendale: anche queste sono cose che dovrebbero, perché la maggior parte, si verifica automaticamente, in caso di necessità.

Potremmo passare giorni a parlare dei tipi di cose che possono andare storte negli ambienti di database e che gli umani generalmente hanno risposto, ma ora abbiamo bisogno di sistemi e strumenti per farlo per noi. Un esempio è una violazione dei dati e quindi, quando pensiamo ai database, e faccio questa domanda apertamente in varie forme: cosa succede ai database quando distogliamo gli occhi dalla sfera e qualcosa di critico va storto? Soprattutto se non esiste un sistema che controlla le prestazioni e la sicurezza e altri aspetti importanti dell'esecuzione dei database.

Bene, ciò che potrebbe accadere è questo, questo è uno screenshot di alcune delle recenti violazioni degli ultimi due o tre anni. Invariabilmente, questi provengono tutti da un sistema di database e, invariabilmente, c'è stato qualche problema in termini di sicurezza o controllo, o accesso che si è verificato, e nell'angolo in alto a sinistra stiamo guardando 152 milioni di account Adobe, dove ogni dettaglio di questi clienti è stato violato. E nel caso in cui fossero stati messi in atto gli strumenti adeguati per tracciare e catturare l'incidente e controllare la sicurezza, avremmo potuto evitare alcuni di questi, i primi due centinaia di registrazioni rubate avrebbero potuto avvisarci e avremmo fermò i successivi centocinquanta milioni.

Quindi arriviamo al punto chiave di questo intero viaggio, che ci accompagna, cioè: perché abbiamo bisogno di sistemi migliori? Perché non possiamo semplicemente lanciare più corpi in questa cosa, che abbiamo davvero superato il punto di svolta a mio avviso, e certamente credo che ci sia un caso che è stato dimostrato di recente, che ha lanciato più DBA, amministratori e più persone a questa cosa non risolve il problema. Abbiamo bisogno di un migliore set di strumenti e un migliore set di sistemi.

Ecco i miei cinque principali motivi che ritengo supportino questo, e sono classificati in ordine di importanza, in base a ciò che vedo in queste aziende private e in quegli stati che sono ambienti governati, le sfide che devono affrontare con gli ambienti di database, e gestirli.

Sicurezza e conformità: il numero uno. Sai, controllando chi ha accesso, da dove hanno accesso, quando hanno accesso, con quale frequenza hanno accesso, da dove hanno avuto accesso. Potenzialmente i dispositivi che hanno effettivamente toccato, i tipi di cose che hanno guardato e la conformità che lo circonda. Fare in modo che gli esseri umani eseguano rapporti 30 giorni dopo per dirci se le cose vanno bene, ma non è più appropriato, deve accadere in tempo reale.

Prestazioni e monitoraggio: sembra un gioco da ragazzi, ma inevitabilmente non lo è. Sia che utilizziamo strumenti open source o alcuni strumenti commerciali di terze parti, inevitabilmente non abbiamo perso l'imbarcazione, in molti modi, con i tipi di monitoraggio delle prestazioni richiesti e i dettagli quali e la capacità di rispondere in tempo .

Rilevazione e risposta agli incidenti: deve essere una cosa istantanea in tempo reale e, inevitabilmente, abbiamo bisogno di un sistema per farlo per noi, o almeno avvisarci rapidamente in modo che possiamo affrontarlo, in modo che i pochi problemi che sorgono vengano risolti con rapidamente e non sfuggire al controllo.

Gestione e amministrazione - di nuovo, pensiamo che questi problemi siano risolti, non lo sono. L'obiettivo dei problemi affrontati dai team di database, in particolare dai DBA in cui un sistema dovrebbe occuparsi delle cose per noi, non abbiamo ancora risolto il problema, è ancora una cosa reale.

E fin dall'inizio con la progettazione e lo sviluppo, quando iniziamo a costruire questi strumenti, costruiamo gli ambienti di database, siamo in grado di lanciare gli strumenti appropriati allo sviluppo e al testing e all'integrazione, piattaforme. Questa non è ancora una cosa facile da fare per noi, e in questo intero viaggio, ci porta in qualche modo allo stesso messaggio, secondo cui abbiamo bisogno di sistemi e strumenti migliori per aiutarci a ottenere i risultati di cui abbiamo bisogno il nostro ambiente di database, quindi le aziende che generano valore dai nostri clienti. Non possiamo semplicemente continuare a lanciare più corpi e più DBA, la scala è troppo grande, la velocità è troppo veloce e il volume è troppo alto. Detto questo, Eric, potrei tornare da te.

Eric Kavanagh: lo adoro, abbiamo un sacco di terreno coperto gente, molti potenziali contatti, e andiamo avanti e consegniamo le loro chiavi a Bullett in un solo secondo.

Bullett Manale: Va bene.

Eric Kavanagh: Oh, portiamolo via e Bullett, ora te lo sto consegnando, e il pavimento è tuo.

Bullett Manale: Va bene, grazie. Penso che siano stati fatti molti punti positivi. Volevo parlare rapidamente solo per un secondo di Idera, chi siamo, e poi entreremo. Parlerò dello strumento di cui penso molte cose di cui stiamo parlando, possiamo tipo di set e tipo di discussione di alcune aree in cui queste allineano, con questo strumento, il prodotto Diagnostic Manager.

Ora, quello che voglio fare per primo, è solo quello di darti un po 'di informazioni su chi sia Idera; siamo in giro da circa il 2003 e quindi abbiamo iniziato con solo gli strumenti di SQL Server, ed è quello su cui ci concentreremo oggi, è che sarebbe il prodotto Diagnostic Manager. Ma puoi vedere tutti i secchi delle cose che abbiamo qui e di recente, come è stato menzionato in precedenza, abbiamo acquisito Precise e attraverso l'acquisizione, abbiamo anche Embarcadero, e quindi abbiamo un portafoglio di prodotti piuttosto buono.

In termini di monitoraggio delle prestazioni, in termini di SQL Server, il prodotto di cui voglio parlare, che allinea questi argomenti di cui stiamo discutendo, è Diagnostic Manager. Ora, questo è un prodotto che esiste da molto vicino all'inizio dei giorni di Idera, e ho avuto la fortuna di farne parte da circa il 2005. E ho visto molti cambiamenti in termini di SQL Server, il passaggio da fisico a virtuale, tutto quel tipo di cose che sono successe e anche le esigenze dei DBA man mano che gli ambienti crescono e quel tipo di cose.

Ciò che ho iniziato è che l'utente tipico del nostro prodotto è il DBA, quindi quando parliamo per la prima volta con i potenziali clienti, sono principalmente i DBA con cui stiamo parlando. Non stiamo parlando con i responsabili IT o i direttori, ad un certo punto potrebbe arrivare a quel livello, ma l'inizio iniziale è che il DBA ha un problema, il DBA cerca di risolvere il problema e molte volte abbiamo Vado a scaricare e provare il prodotto come parte di questo. O ottieni il responsabile dei dati o il DBA o il DBA recitante, il ragazzo che è abbastanza fortunato da essere il più tecnico nella stanza, in alcuni casi. Ora, quando arrivi agli ambienti aziendali più grandi, ovviamente, otterrai i DBA in piena regola che saranno quelli che usano lo strumento. E sono andato avanti e ho appena aggiunto un po 'di disturbo qui da Wikipedia. In un certo senso va oltre le responsabilità del DBA come dice Wikipedia, è quello che fanno.

Se analizzi l'elenco qui, molte di queste cose, non le leggerò, ma otterrai molte delle cose tipiche a cui potresti pensare, e poi su una di esse, hai il monitoraggio e l'ottimizzazione delle prestazioni del database, e questo è piuttosto grande. E ciò che è interessante, è quando parli con il DBA, sono sempre quelli che vengono biasimati per primi, quando si tratta di problemi, e potrebbe non essere davvero colpa loro, ma quando c'è un problema di prestazioni, in genere con un'applicazione che è legato a un database DBA, sono quelli che hanno la colpa, quindi sono sempre alla ricerca dei motivi per cui non è colpa loro. In molti casi è quello che possono usare questo strumento, Diagnostic Manager, per aiutarli a fare.

Ma alla fine, anche se il database non funziona, allora molte altre cose non contano davvero, le tue applicazioni non funzionano, quindi non importa davvero per molte di queste cose. In primo luogo, vogliamo essere in grado di assicurarci che l'utente sperimenti il ​​modo in cui lo conosciamo, non sia diminuito, è qualcosa a cui i DBA si impegnano sempre. E penso che, se si guardano i motivi per cui le persone in genere acquistano e utilizzano il prodotto SQL Diagnostic Manager, uno dei primi motivi, probabilmente non è il primo, non ultimo o meno, ma è un po 'uguale su tutta la linea, e a seconda di chi parli, questi motivi, quasi uno o due di loro sono sempre, c'è un qualche tipo di necessità in giro.

Ma il primo è solo essere in grado di avere quella vista centralizzata delle istanze come un SQL che stanno gestendo. E la cosa divertente è che in molti casi, se chiedi a un DBA, "Quanti casi riesci a gestire?" Il numero cambia così spesso, che in alcuni casi non ne sono davvero sicuri. Quindi hai bisogno di qualcosa di più che essere in grado di lanciare tutto sullo schermo. Volete afferrare quelle informazioni, volete darle un senso, e quindi questa è una delle cose che Diagnostic Manager può sicuramente aiutare, è essere in grado di fornirvi quel tipo di vista nell'ambiente.

E non è solo una vista nell'ambiente, ma è una vista con cui il DBA, l'amministratore del database, è a suo agio ed è una console incentrata sul DBA, se vuoi. È fatto per un amministratore di database. Ci sono molti strumenti di monitoraggio là fuori, ci sono molti strumenti di prestazioni là fuori, ma come ho detto, alla fine della giornata, il DBA vuole uno strumento progettato per un DBA, perché ci sono molte cose specifiche per quello che fanno nel loro giorno per giorno.

Detto questo, hai SCOM, hai HPF, hai tutte queste altre tecnologie, ma vogliono qualcosa di particolare per quello che stanno facendo. Penso che possiamo aiutare in quell'area con questo prodotto, vedrai quando ci entreremo in un secondo. L'altra cosa che vediamo con il DBA che è sicuramente una delle cose che abbiamo toccato anche prima, è che devono essere in grado di vedere cosa sta succedendo, ovviamente, e devono essere in grado di guardare attraverso l'intera impresa e hai un po 'di tranquillità nel sapere cosa sta succedendo. Ma allo stesso tempo, non sono seduti lì a fissare le console.

Ricordi tutti quei punti elenco che hai visto in quella lista, che ho appena tirato su? Devono fare anche quelle altre cose, quindi non si tratta solo di aspettare che gli incendi si spegnano. In molti casi ci saranno riunioni o molte finestre di manutenzione relative all'amministratore del database sono in esecuzione nel cuore della notte quando dormono, quindi devono avere la possibilità di tornare indietro e vedere cosa è successo . In molti casi, se non si rileva qualcosa quando si verifica, una volta che il problema è scomparso, o almeno con SQL Server, diventa una specie di problema in cui si ha a che fare con la situazione in cui non si non ha più alcun residuo di quel problema. E questi problemi scompaiono, così come i resti, il che significa che hai meno problemi da risolvere, hai meno informazioni con cui lavorare.

Detto questo, questa è sicuramente una delle cose con cui Diagnostic Manager può aiutarti, è darti quella visione del passato per interrogare le informazioni del passato, "Ho avuto un avviso con il blocco, ho avuto problemi con il deadlock, abbiamo avuto cose che stavano accadendo in termini di risorse? ”Posso tornare indietro e richiedere tali informazioni. Posso approfondire punti specifici nel tempo. Sarei in grado di fare tutte queste cose direttamente dallo strumento.

Tutte queste cose, indipendentemente dal fatto che si tratti di un'applicazione interna o esterna, i DBA vogliono sapere, perché vogliono essere in grado di vedere cosa sta causando il problema. Non importa se è stato qualcuno all'interno dell'organizzazione o qualcuno al di fuori dell'organizzazione a scrivere il codice; vogliono ancora essere in grado di isolarlo, in modo che sappiano che il problema sta accadendo e sanno da dove proviene.

Quindi le prestazioni e la responsabilità sono una parte fondamentale di ciò che fa il nostro prodotto. Siamo in grado di fornire tutti questi dettagli, e ciò che è carino, è che hai la possibilità di approfondire. Se c'è un collo di bottiglia, è possibile correlarlo all'applicazione, all'utente, al database, alla query. E ancora una volta, è una specie di pistola fumante. Si ottiene una correlazione diretta tra quando viene eseguita questa query, che cosa sta facendo? E non si tratta solo della query stessa, in termini di esecuzione in sé e per sé, ma la query peggiora nel tempo? E anche a queste cose si può rispondere con il prodotto, che è sicuramente qualcosa che se stai cercando di essere proattivo, è bello poter dire: "Ehi, ecco una domanda che è andata male, ma ragazzo guarda man mano che avanza, possiamo vedere che sta andando sempre peggio, posso fare qualcosa al riguardo ".

Se andiamo nella prossima area qui; e questo è probabilmente - direi che questo è uno dei più grandi. Una delle domande che faccio, quando sto mostrando il nostro prodotto, chiederò sempre all'amministratore del database: "Come si sente parlare di un problema relativo ai database di SQL Server?" Ed è molto divertente, perché la maggior parte delle volte - ora concesso, la maggior parte delle volte stanno guardando il nostro prodotto, perché in molti casi stanno cercando di risolvere un particolare bisogno. Ma è interessante ascoltare il tipo iniziale di cose - almeno con SQL Server, è che era una specie di - sai, nei primi giorni di SQL Server avevi SQL Server e poi avevi Oracle. E tutti avevano Oracle, e SQL Server era un po 'come il, per mancanza di una migliore espressione, il figliastro dai database dai capelli rossi, quando è iniziato.

E poi, quando Microsoft ha aggiunto ulteriori funzionalità, è diventato un po 'più uno strumento aziendale. E ovviamente, da allora ha fatto molta strada. Ma il punto è che, una volta, si potrebbe sostenere che i database non sono stati considerati critici ai giorni nostri. E questo è cambiato nel tempo. Ora, per questo motivo, in molti casi le persone stanno provando a metterci le mani intorno e dicendo: “Sai cosa? Ho tutti questi database di SQL Server, sto provando a gestirlo. "E invece di ascoltare i problemi dell'help desk o i problemi delle persone specifiche che, come gli utenti stessi, " stanno cercando dei modi per aggirare il problema. Stanno cercando modi per essere consapevoli di quelle situazioni prima che si verifichino.

E così con Diagnostic Manager, questa è una delle cose che stiamo cercando di fare, è almeno in grado di fare in modo che il DBA sia il primo a conoscere queste situazioni o quei problemi, in modo che possano fare qualcosa al riguardo, o proprio quando accadono, o per fare un passo ulteriore, per analizzare questi sistemi che sta monitorando. E essere in grado di darti consigli proattivi che miglioreranno le prestazioni di quell'istanza e di poterlo fare su base regolare. Ad esempio, è necessario aggiungere un indice, in base al carico di lavoro; quel tipo di cose, anche gli strumenti in grado di fare. Quindi vedremo molto nello strumento.

L'altra cosa e l'ultima cosa che è in questa lista, che è un po 'più di una descrizione generale, ma è qualcosa che vale sicuramente la pena notare. E soprattutto, man mano che entri nei più grandi tipi di situazioni a livello aziendale, in cui hai molte istanze, ci sarà sempre qualche cosa oscura che vorrò monitorare, se sono l'amministratore del database, per esempio. E quindi ciò che proviamo a fare è anticipare in termini di ciò che il tipico DBA vorrà monitorare.

Detto questo, si sarebbe anche in grado di - ci sarà sempre qualcosa di nuovo. Quindi ti abbiamo fornito un modo per aggiungere qualsiasi metrica sia necessaria per monitorare e gestire dopo aver aggiunto il punto di installazione. Quindi qualsiasi contatore PerfMon, contatore WMI, oggetto contatore SQL Server; tutti quelli possono essere incorporati nello strumento. Hai la possibilità di aggiungere ulteriori query che possono essere incorporate nei tuoi intervalli di polling.

E l'ultima cosa che vale anche la pena notare è che possiamo aggiungere e comunicare effettivamente con vCenter e Hyper-V per essere in grado di estrarre le metriche da quegli ambienti. Perché una delle cose che abbiamo identificato con il DBA è che in genere non fanno parte delle operazioni in modo specifico. E in genere non hanno necessariamente l'ambiente vCenter a loro disposizione o quel genere di cose a loro disposizione.

E quindi il problema è che se hanno a che fare con un'istanza di SQL Server e sono state allocate risorse, ma quell'istanza è virtualizzata, può sembrare che abbiano tutte le risorse del mondo, quando stanno solo monitorando ciò che è sul sistema operativo guest. La realtà è che sull'host potrebbero esserci 30, o 40 o 50 o 100 altre macchine virtuali a cui stanno tentando di accedere e che contendono tali risorse. E l'unico modo per vedere effettivamente quello è comunicare con quegli altri ambienti e con quelle interfacce, in questo caso, che facciamo.

Hai la possibilità di aggiungere quegli altri tipi di segnalini nello strumento. Ora non si tratta solo di essere in grado di monitorare quei contatori, ma di poter creare quei nuovi contatori, che si introducono nel prodotto, rendendoli parte dello strumento, come se fossero una metrica out-of-the-box . Una cosa pronta all'uso che vorresti monitorare; quindi ciò significa poterli incorporare nei loro cruscotti. Significa essere in grado di aggiungerli ai propri report personalizzati, essere in grado di impostare ovviamente soglie e avvisare su di essi, ma anche basarli ed essere in grado di impostare le soglie con una certa conoscenza, su dove impostarle in base a cose come la tua baseline e cosa è normale. Quindi, hai molti di quei tipi di cose che sono anche nel prodotto.

Quello che ti ho fornito è quello che chiamo "i risultati principali per Diagnostic Manager", e posso andare avanti e darti un piccolo assaggio andando nel prodotto. Quello che sto per fare è condividi il mio schermo, okay, e trasciniamo questo. Quindi, quello che vedrai, questa è la console per Diagnostic Manager. E come ho già detto, vai al primo prodotto principale, in grado di guardare cose da una sorta di vista a livello aziendale. Ci sono molti diversi esempi di ciò all'interno dello strumento. Abbiamo una sorta di vista in miniatura; abbiamo più di una vista simile a una griglia. Abbiamo anche, in termini di flessibilità, avere anche una console basata sul Web. La console basata sul Web ha altre viste a tua disposizione, come mappe chiave e cose del genere. Ma il punto è che hai quella capacità di guardare e vedere le cose ad alto livello, ma man mano che si verificano problemi, andrai a scavare un po 'più a fondo nello strumento e vedrai effettivamente il problema specifico lems, e ho un modo per capire e sapere cosa sta succedendo. E ovviamente questo è molto importante.

Ora, in termini di poter effettivamente vedere cosa è successo in passato; se sto osservando un problema accaduto ieri, o una settimana fa, in quella situazione, sai, avrai la necessità di essere in grado di passare a una particolare istanza di SQL. E la buona notizia è che, se sai a che ora si è verificato il problema all'interno del prodotto, puoi andare direttamente al browser della cronologia. E posso indicare un momento specifico della giornata; potrebbe essere di un paio di settimane fa, potrebbe essere di ieri. Ma qualunque giorno scelga nel calendario, mi verranno presentati i diversi intervalli di polling. Nel qual caso ora, sto effettivamente vedendo cosa avrei visto se avessi visto la console il 20 aprile alle 13:37

Quindi sono in grado di tornare indietro nel tempo, e poi una volta che lo faccio, tutte le diverse schede che vediamo qui rifletteranno quel punto specifico nel tempo, comprese le query che potrebbero essere state eseguite male, incluso forse se Ho avuto sessioni con il blocco. Tutto quel genere di cose verrebbe mostrato nello strumento e mi consentirà ovviamente di sfruttare quelle informazioni storiche per essere in grado, sapete, di risolvere il problema. Ora su quella nota, quando stiamo parlando della storia, l'altra cosa che vale la pena notare qui è che non è solo usare la cronologia per risolvere i problemi. Quella storia è ovviamente molto preziosa, per altri motivi. E uno dei più grandi è quello di essere in grado di prendere decisioni in modo efficiente e di essere in grado di prendere decisioni rapidamente, con le giuste informazioni. Quindi tutta la storia, tutte le informazioni che stiamo raccogliendo, possiamo denunciarle.

Se qualcuno viene da me e dice: "Ho questa fantastica nuova applicazione. Cambierà il mondo come lo conosciamo. Oh, a proposito richiederà un database, e oh a proposito I / O sulla macchina in cui si trova quel database. " Se so che entrando in esso, allora posso sfruttare quelle informazioni per essere in grado di fornire una classifica di tutti i miei server di produzione, basata forse sugli ultimi sette giorni di raccolta. E sarei in grado di giungere molto rapidamente alla conclusione su quali istanze abbia più senso impiegare quel database. Quindi è quel tipo di informazione storica che ovviamente è anche molto preziosa.

In termini di domande stesse; in termini di visualizzazione delle query, abbiamo molti modi diversi per farlo nello strumento. E quello che mi piace guardare è la Query Waits View, perché Query Waits View è molto utile in termini di valutazione. Se ho un collo di bottiglia che si sta verificando, per poter essenzialmente identificare tutte le diverse aree che stanno interessando quella specifica, particolare query; non solo la query stessa e qual è l'impatto di quella query, ma anche, sai, da quale applicazione proviene, da quale sessione proviene, quale utente l'ha chiamata e tutta quella roba, posso vedere che, ovviamente, le informazioni in tempo reale, ma ho anche la possibilità di guardare quei dati del passato. E quindi questa è una delle cose qui, e ho dato il via a una sceneggiatura, ma devo aspettare che compaia.

Mentre aspettiamo questo, voglio - e so che abbiamo poco tempo, quindi ho voluto parlare un po 'anche del fatto che le notifiche di avviso sono proattive. E quando parli di quel tipo di cose, come ho detto, essendo la parte proattiva, ci sono molti strumenti che fanno avvisi. La parte difficile non è l'invio di un'e-mail. La parte difficile non sta scrivendo nel registro eventi né sta generando una trap SNMP. La parte difficile è sapere quando inviare tale avviso nei momenti appropriati. E così da ciò deriva un sacco di dover fare dei calcoli, dover capire: "Che cosa c'è in quella particolare istanza e cosa è normale per quanto riguarda quell'istanza?"

Quindi, per tutte le metriche che hanno senso farlo, basiamo tali metriche. In realtà ti mostriamo la linea di base, ti mostreremo la soglia su cui è attualmente impostata. E poi l'altra cosa bella a riguardo, è che, diciamo, ho impostato le mie soglie in questo caso sei e dieci solo per questo esempio. Tra sei settimane, se torno a questa istanza, questa linea di base può cambiare completamente, perché una delle cose che facciamo quando calcoliamo la linea di base, per impostazione predefinita, è un calcolo continuo di sette giorni. Quindi mi dà sempre una versione aggiornata della baseline. E cosa succede se quella linea di base si sposta sulle mie soglie? In questo caso, posso vedere e avvisare le raccomandazioni che sostanzialmente dicono "Ehi, hai una soglia probabilmente impostata in modo errato, specifica di dove vediamo la soglia, e ovviamente dove si trova la linea di base, probabilmente stai andando a ricevere un avviso per qualcosa che è normale. "

E quindi piuttosto che trattare un sintomo di qualcosa di normale, sono in grado di identificare quel tipo di situazione in cui la soglia effettiva è impostata in modo errato. E ciò che mi consente di fare ovviamente è impostare le soglie in base a dove riceverò un avviso. È qualcosa che so essere più un invito all'azione che un'indagine per vedere se è davvero un problema. E penso che una parte dello strumento sia davvero utile in termini di baseline stessa e di essere in grado di calcolare.

Ora, con questo prodotto hai la possibilità di avere effettivamente più baseline; puoi impostarli per diversi periodi di tempo e puoi regolare dinamicamente le soglie in base alle tue baseline, che è anche una parte molto importante del tipo di adattamento alle modifiche che si verificano quotidianamente alle tue istanze di SQL Server . Ora, in questo caso qui, copriamo un sacco di impostazioni delle soglie e ti mostriamo le linee di base. Ma per quanto riguarda gli avvisi reali, la notifica stessa, la cosa interessante di Diagnostic Manager, è che ti fornisce più profili di avviso. Quindi, se ad esempio hai un profilo su chiamata che è dalle 2:00 alle 5:00, allora posso avere un profilo specifico per quel solo intervallo di tempo e posso impostare tutte le condizioni e le impostazioni appropriate qui per la mia risposta.

Ora, la cosa positiva della risposta è che, in alcuni casi, sì, posso inviare un'e-mail, oppure posso sparare e generare una trap SNMP o scrivere nel registro eventi. Ci sono molte altre cose che possiamo fare, ma mentre parlo con i DBA, ciò che piace davvero è il fatto che nella maggior parte dei casi il lavoro svolto è roba ripetitiva. Sono cose che sanno esattamente quando si verifica il problema, cosa fare per risolverlo. Devono solo andare e intervenire. E così man mano che cresci il tuo ambiente, dato che hai più casi, diventa molto più difficile da fare. Quindi una delle cose che puoi fare all'interno dello strumento che ritengo degno di nota è che hai la possibilità di impostare una condizione, ma basandoti su quella condizione per essere in grado di impostare una risposta per eseguire uno script, per eseguire un lavoro, per eseguire un eseguibile. E, il punto è che se decidi di eseguire uno script posso usare parametri, all'interno di quello script che saranno in fase di esecuzione, popolati con le informazioni effettive.

Pertanto, se si verificano problemi con un database specifico, lo script verrà progettato per essere eseguito solo sul database in cui si verifica il problema. Quindi, puoi risolvere dinamicamente i problemi in modo automatizzato, e quindi posso ancora ricevere un'e-mail per tornare indietro e dirmi che "Ehi, c'è stato un problema, ma a proposito, è stato risolto". Lo script è stato eseguito e come DBA lo sai, ma in realtà non hai dovuto entrare e intervenire. Ora, sulla stessa nota di essere proattivi, ovviamente abbiamo anche un'altra caratteristica qui che è la funzione "Analizza". E, ciò che farà è che farà un controllo regolare, contro l'istanza di SQL. E, in alcuni casi, farà un tuffo più profondo in termini di ciò che sta cercando. Verranno eseguite analisi ipotetiche sull'indice. Aggiungo un indice? Posso rimuovere un indice? E, ovviamente, tutte queste cose mi aiuteranno con la mia esibizione, ma ancora una volta si tratta di essere proattivi. Si tratta di essere in grado di prendere decisioni prima che le cose si interrompano e di farlo funzionare meglio. E, quindi, in molti casi, è proprio quello che stiamo cercando di fare qui.

Tornando a Query Waits di cui stavamo parlando prima; come puoi vedere, c'è un grande picco qui. Ho eseguito uno script in precedenza che ha appena causato alcune attività di attesa e, come ho detto prima, abbiamo un modo davvero unico in cui puoi approfondire queste informazioni. Se voglio vedere quale applicazione era; Vedo che proveniva dall'applicazione NoSQL. Saremmo in grado di vedere il database a cui era legato, la sessione, l'utente e quindi, se lo desidero, posso classificarlo anche in base alle mie attese. Quindi, posso dire, di tutte le attese che stavano accadendo in quella finestra del tempo, quali stavano accadendo di più? E se vedo che quando è successo di più, la cosa davvero bella è che posso approfondire quel tipo di attesa e posso vedere tutti i comandi. Se guardi qui, stavano facendo accadere quell'attesa. E posso anche vedere principalmente l'applicazione che stava facendo aspettare.

Quindi sporge come un pollice dolente. Posso immediatamente andare a dire: "Questa è l'applicazione che sta causando il mio collo di bottiglia. Ora qual è stata la query che è stata eseguita? A quale utente è stata eseguita? Quale database è stato eseguito?" E così via. Quindi, si spera che abbia senso, e aiuta anche in termini di assicurarsi che non si abbia la latenza nel proprio ambiente, in relazione ai database. Speriamo che sia utile. A questo punto andrò avanti e lo passerò indietro, e immagino possiamo continuare da lì.

Eric Kavanagh: Sicuro. Quindi, suppongo che lo lancerò ai nostri esperti del giorno. Mark, forse prima vuoi commentare e fare un paio di domande. Quindi Dez, puoi entrare.

Mark Madsen: Sì, grazie, mi sono davvero divertito a guardarne un po '. È un monitoraggio molto più intelligente di quello che sono abituato a vedere. Sono curioso di gestire i dati dietro questo; la gestione delle metriche che è possibile tenere traccia e, sai, cercare cose come spostare le linee di base in particolare, che è uno dei miei punti deboli del mio animale domestico, con dashboard. Come gestisci quei dati, e la seconda parte, è con, sai, le metriche di base, come il tipo di spostamento - hai la possibilità di spostare automaticamente anche le soglie, in modo che non debba tornare indietro e ripristinare le soglie a mano, quando si sposta una linea di base?

Bullett Manale: Sì, e quindi la cosa bella è che puoi decidere. Puoi fare entrambe le cose. Posso impostare una soglia e renderla un'impostazione statica, oppure posso selezionare la casella per dire "Rendi questa una soglia dinamica, che cambierà quando cambiano le mie linee di base". E ho la possibilità e lo strumento di impostare una finestra predefinita di tempo per la mia linea di base. Ma se dovessi, potrei avere una finestra di base separata, ad esempio, dalla mia finestra di manutenzione dalle 2:00 del mattino diciamo fino alle 5:00 del mattino, perché ho intenzione di tassare il mio CPU, i miei dischi e tutto il resto perché è in quel momento che facciamo tutta la nostra manutenzione. Quindi, automaticamente, se lo selezionassi per farlo, regolerebbe automaticamente le mie soglie in modo da essere al di fuori di qualsiasi cosa sia normale per quelle metriche che Scelgo di farlo con. Mi permetterebbe di farlo. Fondamentalmente hai la possibilità all'interno dello strumento di impostare finestre di tempo, che sono le tue finestre di base e ogni finestra può essere trattata come un'entità separata, in termini di regolazione dinamica del baseline che può essere fatta. E puoi aggiungere quante finestre della tua baseline quanti anni hai è necessario, se questo ha senso. Potresti avere una finestra del fine settimana, un giorno della settimana durante l'orario di lavoro, una finestra di manutenzione che si verifica nel mezzo della notte e così via e così via.

Mark Madsen: Grazie.

Bullett Manale: Credo che tornando alla prima parte della domanda, abbiamo e raccogliamo tutte queste informazioni. Non ho davvero parlato dell'architettura, ma abbiamo un repository back-end, che hai il controllo completo sulla conservazione di quei dati, ma abbiamo anche un servizio che funziona nel bel mezzo della notte che va e viene tutti i nostri calcoli di base e prende quei dati, li raccoglie e li dà un senso. E ovviamente, oltre a questo, hai anche numerosi rapporti che possiamo usare per riferire contro le tue linee di base, per metriche specifiche. E hai anche la possibilità di confrontare le tue baseline dello stesso server, per la stessa metrica per diversi periodi di tempo. Puoi vedere se si sono verificate differenze o qual è il delta. Ci sono anche molti di questi tipi di opzioni.

Eric Kavanagh: Dez.

Dez Blanchfield: Una domanda veloce che ho per te: c'è un ampio spettro di cosa può fare questo strumento. Stai vedendo un assorbimento nell'uso di esso nella fase iniziale di sviluppo o è ancora principalmente uno strumento dell'ambiente di produzione? In altre parole, gli sviluppatori ottengono l'accesso e lo utilizzano durante il loro sviluppo iniziale e quindi testano la fase di integrazione? O è ancora prevalentemente utilizzato negli ambienti di produzione?

Bullett Manale: Direi che, per la maggior parte delle volte, lo vediamo negli ambienti di produzione. Dipende dalle situazioni, ma per la maggior parte direi principalmente la produzione e lo facciamo - ed è anche, sai, giusto ricordare che abbiamo prezzi diversi per gli ambienti di sviluppo e test, quindi è un po 'più attraente. Vediamo le persone che lo usano per quegli ambienti, ma direi, se dovessi darti una risposta in un modo o nell'altro, direi che sono principalmente gli ambienti di produzione in cui vediamo che le persone fanno un investimento per questo prodotto .

Dez Blanchfield: Certo, sì ed è stato interessante sapere che hai diversi punti di prezzo, perché ovviamente ci sono carichi di lavoro diversi e più pesanti saranno i lavori in cui tutto il vero lavoro viene svolto. Ma sto vedendo molte organizzazioni, in particolare nel governo e certamente nella difesa, dove lo sviluppo sta ottenendo lo stesso livello di investimenti in strumenti e sistemi degli ambienti di produzione, perché stanno facendo test molto più precisi. In difesa, ad esempio, ci sono team che eseguono miliardi di test, centinaia di miliardi di test su applicazioni, sistemi e strumenti e li monitorano prima ancora di passare ai test di integrazione, perché vogliono assicurarsi che sia stato creato un codice e il database è seduto sotto di esso. Arriva a cento milioni di iterazioni o qualcosa del genere, mentre sei in campo sparando a qualcuno, non va "a sbattere".

Bullett Manale: Sicuro.

Dez Blanchfield: Nella mia esperienza nel mondo dei database di vecchia scuola, pensando che l'ambiente del database è qualcosa che è appena rimasto nei dati e che alcuni di voi conoscono, sono visti molto raramente e di cui si parla molto raramente, quindi quando arriviamo al punto in cui strumenti le app vengono sviluppate, in particolare con piattaforme analitiche, ora sono nei nostri telefoni e nei nostri dispositivi. Stai vedendo i clienti portare la conversazione sulle prestazioni del database e una sorta di gestione del database in una discussione più quotidiana rispetto a semplici tecnici? E so che hai detto prima che principalmente stai parlando con i DBA, ma c'è una tendenza ora in cui si trova nel vocabolario generale, stai vedendo persone in cui stanno discutendo di questi argomenti, al contrario dei geek?

Bullett Manale: Beh, è ​​difficile da dire. Voglio dire, come ho detto per la maggior parte, le persone con cui abbiamo a che fare in termini di processo di vendita sono comunque con i professionisti, che sono i DBA. Quindi, in termini di domanda, stai solo dicendo: "In termini generali, le persone all'interno dell'organizzazione IT stanno diventando più consapevoli del database?" Immagino sia la domanda e direi che probabilmente la risposta è "sì". Probabilmente non la vedo molto, in base a dove mi trovo, su una base quotidiana, ma penso che se capisco la tua domanda, penso che sarebbe la mia risposta.

Dez Blanchfield: Sì, va bene. Probabilmente è una domanda carica, scusa, perché ovviamente i tuoi interessi predominanti, nel tuo mondo, sono il lato tecnico delle cose. Sono curioso di questo nelle mie attività quotidiane, vedo le organizzazioni iniziare a portare questo nella conversazione molto presto. Quindi, quando parlano di nuove iniziative, nuovi progetti, nuovi programmi di lavoro, una delle cose che viene immediatamente è: "Come lo stiamo monitorando, come lo stiamo monitorando, come stiamo affrontando i problemi quando si presentano, piuttosto che lanciare, andare in diretta? "

Bullett Manale: Direi che -

Dez Blanchfield: scusa, vai avanti.

Bullett Manale: Stavo per dire che vedo una tendenza in cui dovrei dire - sai, molte volte in passato avresti ottenuto: "Abbiamo avuto un problema e quindi ora abbiamo bisogno di uno strumento. " E penso che stiamo vedendo un po 'più di accettazione per avere lo strumento in atto prima che si verifichi il problema, se questo ha senso. Quindi direi che sta diventando sempre più normale essere, sai, "Ehi, abbiamo bisogno di uno strumento di monitoraggio, abbiamo bisogno di qualcosa". E le persone stanno sicuramente vedendo il valore di questo prodotto, perché come hai detto prima, aggiungendo solo DBA e aggiungendo nuove istanze, hai bisogno di qualcosa che lo gestisca. Hai bisogno di qualcosa che aiuti nella gestione di questo, ed è per questo che stiamo vedendo molta accettazione anche su questo prodotto, o abbiamo.

Dez Blanchfield: domanda veloce. Dove deve vivere? Deve trovarsi proprio sul back burn della LAN, all'interno del data center, il più vicino possibile agli ambienti del database, o è comodo da qualche parte, potenzialmente nel cloud, un cloud di terze parti con una sorta di tunnel VPN o accesso remoto a vari ambienti? Dove deve trovarsi, per quanto riguarda gli ambienti e il monitoraggio?

Bullett Manale: in termini di architettura, esiste un repository back-end, che è un database SQL Server. Abbiamo la console che può essere un client fat o un thin client; ti diamo la possibilità di entrambi. E abbiamo anche un thin client che si rivolge in modo specifico anche ai dispositivi mobili. Ma in termini di dove questo può effettivamente sedere; può trovarsi in un ambiente, in realtà la parte più complicata al riguardo è che, dalla maggior parte delle informazioni che dobbiamo raccogliere, richiede diritti amministrativi, in alcuni casi o in molti casi. Ora non ti costringiamo a farlo; se vuoi, puoi raccogliere dati e solo per le cose che non possiamo raccogliere, perché non abbiamo i diritti di amministratore, ti faremo semplicemente non vedere tali informazioni, se questa è la tua scelta.

A seconda del sapore, ad esempio se stai parlando di AWS, alcuni ambienti, funziona meglio di altri, ma per quanto riguarda l'ambiente stesso, in genere è sufficiente utilizzare l'autenticazione SA per raccogliere i dati rispetto alle istanze. O se si tratta di un dominio non attendibile, di solito è quello che vorresti fare, ma più domini; fintanto che c'è una fiducia tra di loro, possiamo raccogliere contro quelli. Non importa se si trova su una LAN o sulla WAN, la raccolta stessa è piuttosto trascurabile in termini di quantità di dati che stiamo raccogliendo. Se disponiamo di una connessione WAN di dimensioni sufficienti, non è un problema. Ho visto ambienti in cui hanno filiali in cui hanno server SQL in tutti gli Stati Uniti. Ed è un server su ciascuna di queste posizioni diverse e lo stanno monitorando centralmente. La parte difficile è solo assicurarsi di avere una discreta quantità di connettività per farlo. Spero che questo risponda alla tua domanda, è stato un po 'su tutta la mappa.

Dez Blanchfield: Sì, assolutamente. Grazie. Quindi, due domande veloci che sono state presentate ai partecipanti questa mattina; uno è: qual è l'impatto di - spesso vediamo che gli strumenti di monitoraggio del sistema generano il carico da soli semplicemente monitorando le cose, quindi la domanda era, mi dispiace che sia scivolata via dal mio schermo ora, ma solo per parafrasare; monitorando stiamo generando carico noi stessi? C'è un impatto misurabile dello strumento, solo osservando l'ambiente o è un impatto trascurabile?

Bullett Manale: Ci sarà sempre un po 'di impatto perché deve interrogare l'istanza di SQL Server per recuperare i dati. La domanda come hai detto è: "È trascurabile o è significativa?" Immediatamente stai indicando un'istanza, è trascurabile. Lo facciamo da un po 'di tempo, come ho già detto. Abbiamo oltre 20.000 clienti e posso assicurarti che se causasse un impatto significativo sulle prestazioni, non saremmo in affari. Detto questo, permettiamo anche all'utente di decidere cosa vogliono monitorare. Quindi penso che sia una cosa importante da menzionare, è che ogni ambiente è un po 'diverso.

Un esempio potrebbe essere, con il componente di monitoraggio delle query, una delle cose che abbiamo la capacità di fare, è che possiamo impostare la soglia di ciò che consideri il tuo limite di normalità. Quindi potrebbe essere basato sul tempo di esecuzione della query. Potrebbe essere basato su CPU, I / O, ma ad esempio, diciamo solo che ho impostato il mio tempo di esecuzione a zero millisecondi. In effetti, quello che sto dicendo allo strumento è quello di raccogliere tutte le query che sono state eseguite dall'ultimo intervallo di pull e rendere anche quella parte della mia collezione storica.

Ora, quando lo facciamo, raccoglieremo qualsiasi quantità di query stessimo eseguendo sulla scatola dall'ultimo polling. Ora è elettivo e l'utente ha la possibilità di farlo. Diciamo "Questo è quello che dovresti fare"? No. Ma ti diamo anche la possibilità di farlo nel caso in cui desideri un campione di dati che ti consenta di raccogliere tali informazioni. In generale, hai i mezzi all'interno del strumento per configurarlo e ottimizzarlo esattamente come vuoi in base a ciò che ti piace. Ma hai la possibilità di aprirlo davvero se lo desideri, e raccogliere molte informazioni aggiuntive che potresti non necessariamente regolarmente raccogliere, se questo ha senso.

Dez Blanchfield: Sì, assolutamente. So che stiamo correndo un po 'a lungo, ma ci sono due domande davvero grandi che voglio porti prima di concludere. Entrambi vengono direttamente da me, ma penso che sia meglio se rispondi loro. La domanda in generale era: "Qual è lo scopo della portata dello strumento per quanto riguarda la conoscenza dei sistemi esistenti?" Quindi possiamo semplicemente collegarlo e farlo rilevare automaticamente la piattaforma che è lì, e sapere cosa è normale per quella piattaforma e immediatamente riprendendo come Mark stava parlando in precedenza? Alcune delle conoscenze di base delle piattaforme mettendo, sai, non lo so, potrebbe essere Microsoft Dynamics. Qual è lo scopo della conoscenza della piattaforma con ciò che è normale e in alcuni degli attuali strumenti standard che vengono utilizzati in ambito aziendale?

Bullett Manale: Direi che, in generale, quando iniziamo a raccogliere dati sull'istanza di SQL, lavoriamo con le migliori pratiche per cominciare, in termini di soglie e dove sono impostate. Detto questo, riconosciamo anche che chiunque stai parlando, in termini di migliori pratiche, ogni ambiente è diverso. Quello che faremo inizialmente raccogliamo solo i dati e ciò che raccomandiamo alle persone, puoi provare il prodotto per 14 giorni in più se necessario. Ma dopo circa due giorni, inizierai a popolare i dati di base. Una volta che ha abbastanza informazioni di esempio con cui lavorare, inizierà a fornirti il ​​contesto in termini di linea di base, dove si trova l'intervallo e tutto quel genere di cose. Quindi da lì, se lo desideri, puoi impostare automaticamente le tue soglie da quelle informazioni che sono state raccolte. Ci vuole un po 'di raccolta iniziale e polling per poter iniziare a determinare ciò che è normale, in modo da poter iniziare a spostare le soglie.

Ma la cosa che ritengo degno di nota è che, quando si modificano tali soglie, può essere fatto un gruppo per gruppo delle istanze. Può essere specifico per un'istanza o puoi farlo contro tutte le tue istanze, nonché la possibilità di creare cose come modelli, in modo da poter dire: "Questa è un'istanza di produzione, ma questo è il modello che voglio per assegnargli ". E così quando una nuova istanza di produzione viene online, applichiamo automaticamente quelle soglie, perché ha lo stesso tipo di hardware e di solito ha gli stessi carichi di lavoro, quindi saremmo in grado di farlo anche in questo modo. Spero che questo aiuti in termini di domanda.

Dez Blanchfield: Sì, assolutamente. In effetti, hai effettivamente risposto a un'altra domanda che mi è appena arrivata e che era "Esiste un download di prova?" Posso rispondere, lo so. Sono sicuro che confermerai che esiste un download gratuito e penso che tu abbia detto che erano 14 giorni dal sito web. Puoi scaricarlo e giocarci. Immagino però subito: "Di che tipo di ambiente ho bisogno per essere in grado di eseguire la versione di prova? Posso eseguirlo sul mio laptop e giocare con esso o ho davvero bisogno di un server?"

Bullett Manale: la cosa principale di cui ha bisogno è un repository, un database SQL Server che è 2005 o superiore. Oltre a ciò, ci sono alcuni requisiti minimi di risorse, un requisito .NET, e basta. Quindi, si tratta solo di installare il prodotto e creare un database.

Dez Blanchfield: perfetto. Un'ultima domanda che ti porterò, perché ora siamo a corto di tempo, ma rapidamente, circa due o tre persone mi hanno chiesto: "Devo essere un DBA per essere effettivamente in grado di alzarmi e correre con questo, e giocarci? ”

Bullett Manale: No. Direi che, se sei un DBA, avrai diversi usi dello strumento. Voglio dire, probabilmente ci sarà un po 'più di valore se sei un DBA esperto. Vedrai molta più profondità nello strumento di cui potresti trarre vantaggio. Ma anche come nuovo DBA, o anche come persona che, che non è un DBA, abbiamo molti consigli, e ora sono su quella pagina. Queste raccomandazioni verranno formulate su base regolare e la cosa davvero bella delle raccomandazioni è che ti forniscono i motivi per cui le raccomandazioni vengono fatte. Ma oltre a ciò, avranno anche collegamenti a contenuti esterni che descrivono in modo più dettagliato i motivi per cui vengono fatte anche queste raccomandazioni. Quindi questo si collegherà a siti Web, blog e tutti i tipi di cose esterne di Microsoft, che è esterno.

Ma per rispondere alla tua domanda, è un po ', sai, se sei un DBA senior, ci saranno cose qui, probabilmente ne trarrai vantaggio, che probabilmente non faresti come DBA alle prime armi. Ma allo stesso tempo, è anche una specie di strumento di apprendimento, perché mentre segui questi consigli, inizierai a raccogliere alcune di queste cose da solo attraverso l'uso dei consigli.

Dez Blanchfield: fantastico. Grazie. Mi è davvero piaciuta la parte demo. La presentazione è stata fantastica. La demo è stata fantastica. Rapidamente dalla memoria, c'è un intero centro di risorse sul tuo sito Web che consiglio alle persone di dare un'occhiata anche a. Ricordo di aver passato l'ultima notte per ottenere alcuni dettagli. Hai una vasta gamma di cose, solo dai tuoi blog, dati e conversazioni fino a, dalla memoria, hai anche la maggior parte della documentazione del tuo prodotto online, sì?

Bullett Manale: Sì, è corretto, e il modulo secondo cui ti riferisci è il sito Web community.idera.com. E poi una cosa che vorrei menzionare anche, prima ti chiedevi: "Riconoscerà l'ambiente?" In termini di nuove istanze o di aggiunta di istanze, esiste un altro strumento che consente di rilevare le istanze. Ed è tutto sull'inventario e sulla gestione dell'inventario. Vorrei solo indicarti in quella direzione, in termini di scoprire davvero i casi. Ma per quanto riguarda effettivamente le prestazioni e il monitoraggio, tutto quel genere di cose di cui abbiamo parlato, è qui che entra in gioco il Diagnostic Manager.

Dez Blanchfield: fantastico. Guarda, ottima copertura. Ho davvero apprezzato la tua presentazione. Mi è piaciuta molto la demo dal vivo e questo è tutto da parte mia stamattina, poiché so che probabilmente siamo passati 10 minuti nel tempo. Eric, torno da te.

Eric Kavanagh: Va bene. Ho adorato la demo. Sono contento che tu abbia fatto la demo. Sono contento di averci dato una buona occhiata a ciò mentre facevamo le domande e risposte.

Bullett Manale: Fantastico.

Eric Kavanagh: Perché questo dà alle persone un'idea di ciò che stai guardando, e mi sorprende davvero pensare che stiamo ancora imparando a parlare con questi computer, quando ci si arriva fino in fondo. Voglio dire, questo livello di diagnostica è piuttosto sofisticato e migliora ogni giorno. Stiamo ottenendo molte più informazioni su ciò che sta realmente accadendo. Ma hai davvero bisogno di una persona che trascuri queste cose, le legga e metta quell'abilità cognitiva dietro ciò che stai facendo, giusto?

Bullett Manale: Sì, intendo in molti casi - vorrei poterti dire che questo è un DBA nella scatola, ma ci sono troppe cose che stanno succedendo. Voglio dire, forniamo assistenza e diamo una mano, ma alla fine richiede che le persone prendano decisioni sui dati che stiamo presentando. Non credo che cambierà presto.

Eric Kavanagh: Beh, questa è una buona notizia per le persone reali là fuori, gente.

Bullett Manale: Esatto.

Eric Kavanagh: Avrai voglia di avere qualcuno che lo guardi, una squadra che lo guarda, e imparerai, come hai sentito qui da Bullett, guardando questi consigli che raccoglierai cosa sta succedendo. E sto indovinando da quella storia, e penso che tu abbia toccato questo, Bullett, ma molto rapidamente, che la storia ti consente di riconoscere modelli significativi e quindi essere in grado di identificarli quando accadono in futuro, giusto?

Bullett Manale: è corretto. Una delle cose che possiamo fare è tenere traccia delle prestazioni di una query nel tempo. Ovviamente possiamo anche guardare altre cose, come le linee di base e vederle spostarsi, e ovviamente ricevere avvisi e cose del genere quando ciò accade, quindi hai sicuramente quella capacità.

Eric Kavanagh: Suona bene, gente. Non ci sarebbe voluto molto tempo qui, ma volevo arrivare a quelle domande. Grazie mille per il tuo tempo e la tua attenzione. Archiviamo tutti questi webcast. Salta online su Techopedia.com o InsideAnalysis.com, vedrai i collegamenti da entrambi i luoghi.

E con ciò, ti salutiamo. Grazie ancora, gente, ci vediamo la prossima settimana, altri tre webcast la prossima settimana, martedì, mercoledì, giovedì. Quindi ci sentiamo la prossima settimana, gente. Stai attento. Ciao ciao.

Partner di contenuti Techopedia

Lo staff di Techopedia è affiliato a Bloor Group e può essere contattato utilizzando le opzioni sulla destra. Per informazioni su come lavoriamo con i partner del settore clicca qui.

• Profilo
• Sito web