Porta via: Il conduttore Eric Kavanagh discute delle previsioni con il Dr. Robin Bloor, Rick Sherman e IDERA Bullett Manale.
È necessario registrarsi per questo evento per visualizzare il video. Registrati per vedere il video.
Eric Kavanagh: Signore e signori, ciao ancora una volta e bentornati alla serie di webcast di Hot Technologies! Mi chiamo Eric Kavanagh, sarò l'ospite del seminario web di oggi, chiamato "Risparmio di tempo, denaro e difficoltà con le previsioni ottimali". "Naturalmente ho perso la prima parte del titolo," I migliori piani previsti ". Parliamo sempre a questo proposito in questo spettacolo. Quindi, Hot Technologies ovviamente è il nostro forum per capire quali sono alcuni dei fantastici prodotti oggi disponibili nel mondo, il mondo della tecnologia aziendale, cosa fanno le persone con loro, come funzionano, tutto quel tipo di cose divertenti.
E l'argomento di oggi, come suggerisco, riguarda le previsioni. Stai davvero cercando di capire cosa accadrà nella tua organizzazione. Come farai felici i tuoi utenti, qualunque cosa stiano facendo? Se stanno facendo analisi, se stanno facendo un vero lavoro, stanno affrontando clienti reali con sistemi transazionali, qualunque sia il caso, vuoi capire come funzionano i tuoi sistemi e cosa sta succedendo, e questo è ciò di cui parliamo oggi. È un po 'divertente perché la previsione non è qualcosa che mi piace fare, perché sono superstizioso, come penso che se prevedo troppo, accadranno cose brutte, ma sono solo io. Non seguire il mio esempio.
Quindi, ecco i nostri presentatori oggi, i tuoi veramente nell'angolo in alto a sinistra, Rick Sherman chiama da Boston, il nostro amico Bullett Manale di IDERA e il nostro dottor Robin Bloor. E con ciò, lo consegnerò a Robin e ricorderò solo alla gente: fai domande, non essere timido, amiamo le buone domande, ben distribuiscile ai nostri presentatori e agli altri oggi. E con ciò, Robin, portalo via.
Robin Bloor: Ok, bene, dato che sono in pole position come si suol dire, ho pensato di raccontare una storia SQL oggi, perché è lo sfondo di ciò che la discussione sta andando avanti e inevitabilmente non si scontrerà perché Rick non si sta concentrando su questo e non si scontrerà con ciò che Rick ha da dire. Quindi, nella storia di SQL, ci sono alcune cose interessanti su SQL perché è così dominante. Vedi, questo è un refuso, SQL è un linguaggio dichiarativo. L'idea era che potevi creare una lingua in cui avresti richiesto ciò che volevi. E il database avrebbe capito come ottenerlo. E in realtà ha funzionato piuttosto bene, ma ci sono un certo numero di cose che vale la pena dire al riguardo, le conseguenze di basare l'intero settore IT su un linguaggio dichiarativo. L'utente non conosce o si preoccupa dell'organizzazione fisica dei dati, e questo è il bello del linguaggio dichiarativo - ti separa da tutto ciò, e anche preoccupandoti di esso - chiedi semplicemente quello che vuoi, e il database andrà a prenderlo.
Ma l'utente non ha idea se il modo in cui strutturano la query SQL influirà sulle prestazioni della query e questo è un po 'un aspetto negativo. Ho visto query lunghe centinaia e centinaia di righe, che sono solo una richiesta SQL, sai, inizia con "select" e continua e continua con le sub-query e così via e così via. E in realtà si scopre che se si desidera una particolare raccolta di dati da un database, è possibile richiederlo in molti modi diversi con SQL e ottenere la stessa risposta se si ha familiarità con i dati. Pertanto, una query SQL non è necessariamente il modo migliore per richiedere dati e i database risponderanno in modo molto diverso a seconda dell'SQL inserito.
Quindi, SQL influenza effettivamente le prestazioni, quindi le persone che usano SQL, è vero per loro, è anche vero per i programmatori SQL che usano SQL e hanno ancora meno probabilità di pensare all'impatto che avranno, perché la maggior parte della loro attenzione è in realtà sulla manipolazione dei dati e non sull'acquisizione, messa dei dati. E lo stesso vale anche per gli strumenti di BI, ho visto l'SQL che ottiene, se vuoi, spremere dagli strumenti di BI di vari database e va detto che molto di questo è, beh, non scriverei query SQL come quello. Qualcuno ha creato, se vuoi, un piccolo motore che qualunque siano i parametri, emetterà un po 'di SQL e, di nuovo, che SQL non sarà necessariamente un SQL efficiente.
Poi ho pensato di menzionare la mancata corrispondenza dell'impedenza, i dati utilizzati dai programmatori sono diversi da quelli ordinati. Quindi, il nostro DMS archivia i dati in tabelle, organizza i codici orientati agli oggetti, per lo più programmatori, al giorno d'oggi sta programmando moduli orientati agli oggetti e ordina i dati in strutture di oggetti, quindi non si mappano l'uno con l'altro. Quindi, c'è una necessità di tradurre da ciò che il programmatore pensa che i dati siano a ciò che il database pensa quali siano i dati. Sembra che dobbiamo aver fatto qualcosa di sbagliato perché ciò avvenga. SQL ha DDL per la definizione dei dati, ha DML - linguaggio di manipolazione dei dati - selezionare, proiettare e unire per ottenere quei dati. Ora, c'è pochissima matematica e pochissime cose basate sul tempo, quindi è il linguaggio imperfetto, anche se va detto che è stato esteso e continua ad essere esteso.
E poi, ottieni il problema della barriera SQL, che è sempre più severo del diagramma, in quanto ma molte persone stavano ponendo domande per motivi analitici, una volta che hanno ottenuto la risposta ai termini dei dati della domanda, vogliono porre un'altra domanda. Quindi, diventa una cosa di dialogo, beh, SQL non è stato creato per le finestre di dialogo, è stato creato per chiedere cosa vuoi tutto in una volta. E vale la pena saperlo, perché ci sono alcuni prodotti là fuori che in realtà abbandonano SQL per rendere possibile la conversazione tra l'utente e i dati.
In termini di prestazioni del database - e questo tipo di diffusione si estende a tutto - sì, c'è la CPU, c'è la memoria, c'è il disco, c'è l'overhead della rete e c'è il problema di blocco di più di una persona che desidera avere un uso esclusivo dei dati in un dato momento punto nel tempo. Ma ci sono anche scarse chiamate SQL, c'è molto che si può fare se si ottimizza effettivamente l'SQL, in termini di prestazioni. Quindi, fattori di prestazione del database: cattiva progettazione, cattiva progettazione del programma, concorrenza del carico di lavoro mancante, bilanciamento del carico, struttura delle query, pianificazione della capacità. Questa è la crescita dei dati. E in poche parole, SQL è conveniente, ma non si auto-ottimizza.
Detto questo, penso che possiamo passare a Rick.
Eric Kavanagh: Va bene, Rick, lascia che ti dia le chiavi della macchina WebEx. Portalo via.
Rick Sherman: Va bene, fantastico. Bene grazie Robin, dato che abbiamo iniziato all'inizio della presentazione, la mia grafica è ancora piuttosto noiosa, ma va bene. Quindi, sono d'accordo con tutto ciò di cui Robin ha parlato sul lato SQL. Ma quello su cui voglio concentrarmi un po 'ora è la domanda di dati, che ben presto attraversano molto rapidamente, l'offerta come negli strumenti utilizzati in quello spazio o la necessità degli strumenti in quello spazio.
Prima di tutto, ce ne sono alcuni in ogni articolo che leggi hanno a che fare con big data, molti dati, dati non strutturati provenienti dal cloud, big data ovunque che tu possa immaginare. Ma la crescita del mercato dei database è stata continuamente con SQL, il database relazionale probabilmente a partire dal 2015, è ancora il 95 percento del mercato dei database. I tre principali fornitori relazionali detengono circa l'88 percento della quota di mercato in quello spazio. Quindi, stavo ancora parlando, mentre parlava Robin, di SQL. E in effetti, anche se stessero cercando sulla piattaforma Hadoop, Hive e Spark SQL - che mio figlio, che è uno scienziato di dati, usa sempre ora - è sicuramente il modo dominante per le persone di ottenere i dati.
Ora, dal lato del database, ci sono due grandi categorie di utilizzo dei database. Uno è per i sistemi operativi di gestione dei database, quindi pianificazione delle relazioni aziendali, gestione delle relazioni con i clienti, ERP di Salesforce, Oracoli, EPIC, N4, ecc. Del mondo. E c'è una grande quantità e una quantità crescente di dati che è nei data warehouse e in altri sistemi basati su business intelligence. Perché tutto, indipendentemente da dove e come viene acquisito, archiviato o trattato, alla fine viene analizzato e quindi c'è un'enorme domanda e un aumento nell'uso dei database, in particolare i database relazionali sul mercato.
Ora, abbiamo ottenuto la domanda, abbiamo enormi quantità di dati in arrivo. E non sto parlando solo di big data, sto parlando dell'uso dei dati in tutti i tipi di aziende. Ma accompagnando questo dal lato dell'offerta, per le persone che possono gestire quelle risorse, abbiamo prima di tutto, abbiamo una sorta di carenza di DBA. Secondo il Bureau of Labor Statistics, dal 2014 al 2020 i posti di lavoro DBA cresceranno solo dell'11 percento - ora sono persone che hanno titoli di lavoro DBA, ma ne parlano bene in un secondo - contro il 40 percento in più spazio annuale di crescita dei dati. E abbiamo molti DBA; in media quello stesso studio di età media è piuttosto elevato rispetto ad altre professioni IT. E poi abbiamo un sacco di persone che lasciano il campo, non necessariamente ritirandosi, ma spostandosi su altri aspetti, andando in gestione o altro.
Ora, parte del motivo per cui se ne stanno andando, è perché il lavoro DBA diventa sempre più difficile. Prima di tutto, abbiamo DBA che gestiscono da soli molti database diversi, database fisici situati ovunque, nonché diversi tipi di database. Ora potrebbe essere relazionale o potrebbero essere anche altri database, anche tipi di database. Ma anche se è relazionale, potrebbero avere uno, due, tre, quattro diversi fornitori che stanno effettivamente cercando di gestire. I DBA in genere vengono coinvolti dopo la progettazione del database o dell'applicazione. Robin ha parlato di come vengono progettati i database o le applicazioni, come viene progettato SQL. Bene, quando si parlava di modellazione dei dati, modellazione ER, modellazione ER estesa, modellazione dimensionale, modellazione dimensionale avanzata, qualunque cosa, in genere programmatori di applicazioni e sviluppatori di applicazioni progettano con l'obiettivo finale in mente - non stanno progettando per l'efficienza della struttura del database stesso . Quindi abbiamo un sacco di design scadente.
Ora, non sto parlando dei fornitori di applicazioni aziendali commerciali; di solito hanno modelli ER o modelli ER estesi. Ciò di cui sto parlando è che ci sono molti più processi e applicazioni aziendali che vengono sviluppati dagli sviluppatori di applicazioni in ogni azienda: quelli non sono necessariamente progettati per l'efficienza o l'efficacia della distribuzione. E gli stessi DBA sono sovraccarichi di lavoro e hanno responsabilità 24 ore su 24, 7 giorni su 7, a volte, continuano a ottenere sempre più database. Penso che abbia un po 'a che fare con le persone che non capiscono bene cosa fanno o come lo fanno. Il loro piccolo gruppo e le persone continuano a pensare: "Beh, tutti questi strumenti sono così facili da usare, possiamo continuare a lanciare sempre più database sul loro carico di lavoro", il che non è il caso.
Il che ci porta ai DBA part-time e accidentali. Abbiamo team IT di piccole dimensioni che non possono necessariamente permettersi un DBA dedicato. Questo è vero per le piccole e medie imprese, dove l'espansione del database e delle applicazioni di database è esplosa nell'ultimo decennio e continua ad espandersi. Ma è anche il caso delle grandi aziende, che in genere hanno fatto data warehousing, analisi di business intelligence per molto, molto tempo. Molto tempo fa ottenevamo DBA dedicati per quei progetti; non riceviamo più un DBA dedicato. Erano responsabili per la progettazione del database, il che va bene, se è qualcuno che ha esperienza.Ma in generale, i DBA sono sviluppatori di applicazioni, spesso assumono quel ruolo come parte part-time del loro lavoro, non hanno una formazione formale e ancora una volta, lo stanno progettando per i loro obiettivi finali, non lo stanno progettando per l'efficienza.
E c'è molta differenza tra progettazione e sviluppo, rispetto all'implementazione e alla gestione. Quindi, abbiamo il "penny saggio, sterlina sciocca", con un piccolo salvadanaio lì, saltando su per ottenere le competenze e le risorse necessarie nei progetti. Pensando che tutti provengono da "Revenge of the Nerds", la mia piccola foto lì. Ora, per quanto riguarda ciò di cui le persone hanno bisogno, quindi abbiamo un uso crescente di database e dati in SQL. Abbiamo un numero limitato di DBA: persone esperte ed esperte in queste situazioni di ottimizzazione, progettazione, gestione e distribuzione. E abbiamo sempre più DBA part-time o accidentali, persone che non hanno avuto la formazione formale.
Quindi, quali sono alcune delle altre cose che stanno prendendo in considerazione il fatto che anche questi database non sono stati ottimizzati o gestiti? Innanzitutto, molte persone ritengono che il sistema di database stesso disponga di strumenti sufficienti per gestirsi. Ora, gli strumenti stanno diventando sempre più facili da fare - progettazione e sviluppo - ma è diverso dal fare una buona progettazione e una buona gestione, pianificazione della capacità, monitoraggio, ecc. Per l'implementazione. Quindi, prima di tutto, le persone presumono di avere tutti gli strumenti di cui hanno bisogno. In secondo luogo, se sei un DBA part-time o accidentale, non sai cosa non sai.
Immagino di aver dimenticato alcune delle frasi lì, così che molte volte non capiscono cosa devono nemmeno guardare nella progettazione o quando gestiscono o gestiscono i database. Se questa non è la tua professione, non capirai cosa devi fare. Il terzo è che SQL è uno strumento di riferimento, quindi Robin ha parlato di SQL e di quanto a volte scarsamente sia costruito o spesso costruito. E anche uno dei miei animali domestici nel data warehousing della BI, nella migrazione dei dati, nello spazio di ingegneria dei dati è che invece di usare strumenti, le persone hanno la tendenza a scrivere codice SQL, procedure memorizzate, anche se usano uno strumento di integrazione dei dati costoso o un costoso Strumento di BI, spesso lo usano davvero solo per eseguire stored procedure. In modo che l'importanza della comprensione della progettazione del database, della costruzione di SQL, stia diventando sempre più importante.
E infine c'è questo approccio al silo, in cui le persone singole guardano i singoli database. Non osservano come funzionano le applicazioni e interagiscono tra loro. E spesso stanno anche guardando i database rispetto alle applicazioni per cui li usano. Quindi, il carico di lavoro che si ottiene sul database è critico nella progettazione, critico nella messa a punto, fondamentale nel cercare di capire come pianificare la capacità, ecc. Quindi, guardando la foresta dagli alberi, le persone sono tra le erbacce , esaminando le singole tabelle e database e non osservando l'interazione generale di queste applicazioni nel carico di lavoro.
Infine, le persone devono esaminare le aree chiave di cui hanno bisogno. Quando hanno in programma di gestire database, devono prima pensare a, sviluppare alcune metriche delle prestazioni incentrate sull'applicazione, quindi devono guardare non solo a come è strutturata questa tabella, come è particolarmente modellata, ma come viene utilizzata? Quindi, se si dispone di un'applicazione aziendale dovuta nella gestione della catena di approvvigionamento, se si stanno togliendo ordini dal Web, se si sta eseguendo la BI - qualunque cosa si stia facendo - è necessario esaminare chi lo sta utilizzando, come lo stanno usando, quali sono i volumi di dati , quando succederà. Quello che stai davvero cercando di cercare sono i tempi di attesa, perché, qualunque cosa accada, tutte le applicazioni vengono giudicate in base al tempo impiegato per eseguire qualcosa, sia esso una persona o semplicemente lo scambio di dati tra applicazioni o processori. E quali sono i colli di bottiglia? Così spesso quando stai cercando di eseguire il debug dei problemi, ovviamente, stai davvero cercando di vedere quali sono i veri colli di bottiglia - non necessariamente come ottimizzare tutto, ma come sbarazzarsi di e spostare le prestazioni su tempi di attesa e throughput - qualunque cosa devi guardare.
E hai davvero bisogno di separare l'acquisizione dei dati, le transazioni, gli aspetti delle trasformazioni nel database insieme all'analisi. Ognuno di questi ha modelli di progettazione diversi, ognuno di essi ha modelli di utilizzo diversi e ognuno di essi deve essere regolato in modo diverso. Quindi, devi pensare a come vengono utilizzati questi dati, quando vengono utilizzati, a cosa servono e capire quali sono le metriche delle prestazioni e quali sono le cose chiave che desideri analizzare in relazione a tale utilizzo. Ora, quando stai guardando il monitoraggio delle prestazioni, vuoi guardare le operazioni del database stesso; vuoi guardare sia le strutture dei dati, quindi gli indici, il partizionamento e altri aspetti fisici del database, persino la struttura del database - che sia il suo modello ER o modello dimensionale, comunque strutturato - tutte queste cose hanno un impatto sulle prestazioni , in particolare nei diversi contro dell'analisi dei dati acquisiti e delle trasformazioni che avvengono.
E come ha detto Robin sul lato SQL, guardare l'SQL che viene eseguito da queste diverse applicazioni su questi database e ottimizzarlo è fondamentale. E esaminando i carichi di lavoro complessivi delle applicazioni e l'ambiente di infrastruttura su cui sono in esecuzione questi database e applicazioni. Quindi, anche le reti, i server, il cloud - qualunque cosa stiano eseguendo - osservando anche l'impatto che queste applicazioni e questi database hanno all'interno di tale conflitto, tutti questi interagiscono nel riuscire a ottimizzare il database.
E infine, quando guardi gli strumenti, vuoi essere in grado di esaminare i tre diversi tipi di analisi correlate a questo. Si desidera esaminare l'analisi descrittiva: cosa sta succedendo e dove, in relazione al database e alle prestazioni dell'applicazione. Vuoi avere la capacità di fare analisi diagnostiche per capire non solo cosa sta succedendo, ma perché sta accadendo, dove sono i colli di bottiglia, dove sono i problemi, cosa sta funzionando bene, cosa non sta funzionando bene? Ma essere in grado di analizzare e approfondire le aree problematiche al fine di affrontare quelle, sia per la progettazione o qualunque cosa tu debba fare.
E infine, il tipo di analisi più aggressivo o proattivo è effettivamente fare alcune analisi predittive, modelli analitici predittivi, qualunque cosa. Sappiamo che il database e le applicazioni funzionano in questo contesto, se aumentiamo la capacità, se otteniamo più utenti, se facciamo più throughput, qualunque cosa stia facendo, essendo in grado di proiettare cosa, come e dove influenzerà il database, le applicazioni, ci consente di pianificare e capire in modo proattivo, dove si trovano i colli di bottiglia, dove possono subire i tempi di attesa e cosa dobbiamo fare per sistemare le cose. Vogliamo quindi disporre di strumenti in grado di implementare le metriche delle prestazioni, monitorarne le prestazioni, come nel caso di questi tre tipi di analisi. E questa è la mia panoramica.
Eric Kavanagh: Va bene, lasciatemi consegnare a - quelle sono due grandi presentazioni, a proposito - lasciami passare questo a Bullett Manale per prenderlo da lì. E gente, non dimenticate di fare buone domande; abbiamo già dei buoni contenuti. Portalo via, Bullett.
Bullett Manale: Suona bene. Grazie Eric. Quindi, molto di ciò che hanno detto Rick e Robin, ovviamente sono d'accordo con il 100 percento. Direi che ho tirato su questa diapositiva, perché penso che sia adatto, non so per quelli di voi che sono fan di "A-Team" negli anni '80, John Hannibal Smith ha avuto un detto che ha sempre detto: "Adoro quando un piano viene elaborato ", e penso che quando parli in particolare di SQL Server, che è il punto focale, che è il prodotto di cui parleremo oggi, SQL Diagnostic Manager, è sicuramente una di quelle cose che tu devi avere; devi essere in grado di sfruttare i dati che hai e di poter prendere decisioni da tali dati e, in alcuni casi, non stai cercando una decisione; stai cercando qualcosa da dirti quando qualcosa sta per esaurire le risorse, quando stai per esaurire le risorse, quando hai un collo di bottiglia, quel genere di cose.
Non si tratta solo di monitorare una metrica specifica. Quindi, con Diagnostic Manager, una delle cose che fa molto bene ti aiuterà in termini di previsione e comprensione specifica dei carichi di lavoro e ne parleremo molto oggi. Lo strumento è pensato per il gestore dei dati, il DBA o il DBA recitante, quindi molte delle cose di cui Rick parlava, il DBA recitazione è così vero. In molti casi, se non sei un DBA, ci saranno molti punti interrogativi che avrai quando arriva il momento di gestire un ambiente SQL, cose che non conosci. E così stai cercando qualcosa che ti aiuti, ti accompagni attraverso quel processo e ti istruisca anche nel processo. E quindi, è importante che lo strumento che usi per questo tipo di decisioni ti dia un'idea dei motivi per cui vengono prese quelle decisioni, non ti dice semplicemente "Ehi, fallo."
Dato che sono il DBA attore, alla fine potrei essere il vero DBA con la vera esperienza e conoscenza per sostenere quel titolo. Detto questo, quando parlavo di essere un amministratore di database, ho sempre mostrato prima questa diapositiva, perché il DBA ha alcuni ruoli diversi e, a seconda dell'organizzazione con cui ti trovi, avrai, questi varieranno da da un posto a un altro - ma in genere, sarai sempre in qualche modo responsabile della tua memoria, della tua pianificazione di quella memoria e della comprensione di anticipare, dovrei dire, di quanto spazio avrai bisogno, sia per i tuoi backup, o se è per i database stessi. Dovrai capirlo e valutarlo.
Inoltre, dovrai essere in grado di comprendere e ottimizzare le cose in base alle necessità e, mentre esegui il monitoraggio dell'ambiente, è ovviamente importante apportare le modifiche in base alle cose che cambiano all'interno dell'ambiente si. Quindi, cose come il numero di utenti, cose come la popolarità delle applicazioni, la stagionalità di un database, dovrebbero essere prese in considerazione quando si eseguono le previsioni. E poi, ovviamente, guardare altre cose in termini di essere in grado di fornire le relazioni e le informazioni necessarie in relazione al prendere tali decisioni. In molti casi ciò significa fare analisi comparative; significa essere in grado di guardare in modo specifico una particolare metrica e comprendere quale sia stato il valore di quella metrica nel tempo, in modo da poter prevedere dove andrà avanti.
Quindi, gran parte dello strumento Diagnostic Manager ha queste capacità e le persone lo usano ogni giorno per poter fare cose come le previsioni, e ho inserito qui la definizione di pianificazione della capacità. Ed è una definizione piuttosto ampia e in realtà piuttosto vaga, che è solo il processo per determinare la capacità di produzione necessaria a un'organizzazione per soddisfare le mutevoli richieste dei suoi prodotti, e alla fine, questo è davvero ciò di cui si tratta: di essere in grado di prendere le informazioni che hai in un modo o nell'altro e di prendere quelle informazioni e prendere decisioni per aiutarti ad andare avanti mentre avanzi nel ciclo di vita dei tuoi database. E così, i tipi di cose che sono le ragioni per cui le persone hanno bisogno di farlo sono ovviamente prima di tutto, nella maggior parte dei casi, per risparmiare denaro. Le aziende, ovviamente, il loro obiettivo principale è quello di fare soldi e risparmiare denaro. Ma nel processo insieme a ciò, ciò significa anche essere in grado di assicurarsi che i tempi di inattività, non ci siano tempi di inattività. E essere in grado di assicurarsi di mitigare qualsiasi possibilità che si verifichino tempi di inattività, quindi impedendo che ciò accada per cominciare, in altre parole, non aspettando che accada e quindi reagendo ad esso.
Oltre ad essere in grado di aumentare la produttività complessiva dei tuoi utenti, renderli più efficienti in modo da poter fare più affari è ovviamente la chiave qui, quindi questi sono i tipi di cose che come il DBA o qualcuno coinvolto nella previsione o capacità la pianificazione dovrà essere in grado di guadare attraverso le informazioni per poter prendere quelle decisioni. E poi, nel complesso, questo ovviamente ti aiuterà ad eliminare gli sprechi, non solo in termini di denaro, ma anche in termini di tempo e in termini di risorse generalmente che potrebbero essere utilizzate per altre cose, possibilmente. Quindi, essere in grado di eliminare tali rifiuti in modo da non avere costi opportunità legati ai rifiuti stessi.
Quindi, detto questo, quali sono i tipi di domande che riceviamo, specifici per la persona che è un DBA? Quando finirò lo spazio? Quello è grande, non solo quanto spazio sto consumando ora, ma quando finirò, basato sulle tendenze e sulla storia passata? Stessa cosa con le effettive istanze di SQL, i database, quali server posso consolidare? Ne metterò alcune sulle VM, cosa ha senso in termini di quali database consoliderò e su quali istanze di SQL dovrebbero risiedere? Tutti questi tipi di domande devono poter ricevere una risposta. Perché nella maggior parte dei casi, se sei un DBA o recitazione DBA, lo consoliderai qualche volta nella tua carriera. In molti casi lo farai su base continuativa. Quindi, devi essere in grado di prendere rapidamente quelle decisioni, non giocare a indovinare quando si tratta di questo.
Abbiamo parlato di strozzature e di dove si verificheranno dopo, potendo anticipare ciò, ancora una volta, invece di aspettare che accadano. Quindi, ovviamente, tutte queste cose stavano parlando, ha senso nel senso che fai affidamento su dati storici, nella maggior parte dei casi, per essere in grado di generare queste raccomandazioni, o in alcuni casi di essere in grado di formulare decisioni tu stesso, di essere in grado di trovare queste risposte. Ma mi ricorda di, quando ascolti le pubblicità radiofoniche per qualcuno che vende titoli o qualcosa del genere, la sua sempre "performance passata non è indicativa di risultati futuri" e quel genere di cose. E la stessa cosa vale qui. Avrai delle situazioni in cui queste previsioni e queste analisi potrebbero non essere corrette al 100%. Ma se hai a che fare con cose che sono successe in passato e conosciute, e essere in grado di prendere e fare il "what if" con molti di questi tipi di domande, ti imbatterai in, è molto prezioso e sta per farti molto più che giocare a indovinare.
Quindi, questi tipi di domande ovviamente verranno fuori, quindi come gestiremo molte di queste domande con Diagnostic Manager, prima di tutto abbiamo capacità di previsione, essendo in grado di farlo nel database, al tavolo e unità o il volume. Per essere in grado non solo di dire "Ehi, eravamo pieni di spazio", ma tra sei mesi, tra due anni, tra cinque anni, se sto pensando a questo, quanto spazio di guida avrò bisogno di budget per? Queste sono domande che dovrò porre, e dovrò essere in grado di usare un metodo per farlo piuttosto che indovinare e alzare il dito in aria e aspettare di vedere da che parte soffia il vento, che è molto molte volte, sfortunatamente, il modo in cui vengono prese molte di queste decisioni.
Oltre a ciò, potendo - sembra che la mia diapositiva sia stata tagliata un po 'lì - ma essere in grado di fornire assistenza sotto forma di raccomandazioni. Quindi, una cosa è riuscire a mostrarti una dashboard piena di metriche ed essere in grado di dire "OK, ecco tutte le metriche e la loro posizione", ma poi essere in grado di farne alcune o avere una certa comprensione di cosa fare, basandosi su questo è un altro salto. E in alcuni casi, le persone sono sufficientemente istruite nel ruolo di DBA per essere in grado di prendere quelle decisioni. E così abbiamo alcuni meccanismi nello strumento che ti aiuteranno in questo, che ben ti mostrano in un secondo. Ma essere in grado di mostrare non solo quale sia la raccomandazione, ma anche di fornire alcuni spunti sul perché quella raccomandazione è stata fatta e poi anche su ciò, in alcuni casi, essere in grado di elaborare uno script che automatizza il anche la soluzione di questo problema è l'ideale.
Passando al prossimo qui, che ben vede, è in genere solo comprensione a livello metrico di ciò che è normale. Non posso dirti cosa non è normale se non so cosa sia normale. E così, avere un modo per misurare ciò che è fondamentale e devi essere in grado di prendere in considerazione più tipi di aree, ad esempio - o dovrei dire i tempi - diversi raggruppamenti di server, potendo farlo in modo dinamico, da un in prospettiva allerta, in altre parole, nel bel mezzo della notte, durante la mia finestra di manutenzione, mi aspetto che la mia CPU funzionerà all'80% in base a tutta la manutenzione che sta succedendo. Quindi, potrei voler aumentare le mie soglie più in alto, durante quei periodi di tempo rispetto a forse nel mezzo della giornata, quando non ho così tanta attività.
Quelle sono alcune cose che ovviamente saranno ambientali, ma cose che puoi applicare a ciò che viene gestito, per essere in grado di aiutarti a gestire quell'ambiente in modo più efficiente e rendere più facile farlo. L'altra area, ovviamente, è quella di poter fornire nel complesso solo i report e le informazioni per poter rispondere a questi tipi di domande "what if". Se ho appena apportato una modifica al mio ambiente, voglio capire quale impatto ha avuto, in modo da poter applicare la stessa modifica ad altre istanze o altri database nel mio ambiente. Voglio essere in grado di avere alcune informazioni o alcune munizioni per poter apportare quel cambiamento con un po 'di tranquillità e sapendo che sarà un buon cambiamento. Quindi, essere in grado di fare questo report comparativo, essere in grado di classificare le mie istanze di SQL, essere in grado di mettere i miei database uno contro l'altro, per dire: "Qual è il mio più alto consumatore di CPU?" O quale sta impiegando più tempo termini di attese e cose del genere? Quindi molte di queste informazioni saranno disponibili anche con lo strumento.
E poi, ultimo ma non meno importante, è solo un'abilità complessiva di cui hai bisogno di uno strumento che sarà in grado di gestire qualsiasi situazione ti capiti, e quindi quello che intendo con questo è, se hai un grande ambiente con un sacco di ad esempio, probabilmente ti imbatterai in situazioni in cui devi estrarre metriche che tradizionalmente non sono metriche che un DBA vorrebbe persino monitorare in alcuni casi, a seconda di quella particolare situazione. Quindi, avere uno strumento che puoi, che è estensibile, per essere in grado di aggiungere ulteriori metriche e di essere in grado di utilizzare quelle metriche nella stessa forma e modo in cui le useresti se usassi un out-of-the-box metrica, ad esempio. Quindi, essere in grado di eseguire report, essere in grado di allertare, baseline - tutto ciò di cui parlava - è anche una parte fondamentale della capacità di fare queste previsioni e renderle in modo da ottenere le risposte che stai cercando per essere in grado di fare quelle decisioni, andando avanti.
Ora il modo in cui Diagnostic Manager esegue questa operazione, disponiamo di un servizio centralizzato, un gruppo di servizi in esecuzione, che raccoglie i dati rispetto alle istanze dal 2000 al 2016. E poi quello che facciamo è prendere quei dati e li inseriamo in un repository centrale e quindi cosa facciamo bene con quei dati, ovviamente, facciamo molto per essere in grado di fornire ulteriori approfondimenti. Ora, oltre a questo - e una delle cose che non ci sono qui - è anche che abbiamo un servizio che funziona nel cuore della notte, che è il nostro servizio di analisi predittiva, che fa un po 'di scricchiolii di numeri e aiuta a capire e aiutarti come DBA o DBA ad agire, per essere in grado di formulare questo tipo di raccomandazioni, per essere in grado di fornire anche alcune informazioni in termini di baseline.
Quindi, cosa mi piacerebbe fare, e questo è solo un rapido esempio di architettura, il grande asporto qui non ci sono agenti o servizi che si trovano effettivamente nelle istanze che stai gestendo. Ma ciò che mi piace fare è semplicemente portarti all'applicazione qui e darti una breve demo. E lasciami uscire anch'io, e farlo accadere. Fammi sapere, penso Eric, riesci a vederlo bene?
Eric Kavanagh: Ho capito adesso, sì.
Bullett Manale: OK, quindi ti guiderò attraverso alcune di queste diverse parti su cui ho parlato. E essenzialmente iniziamo con il tipo di cose che sono più sulla falsa riga di qualcosa che devi fare, o qui c'è qualcosa che è un punto nel tempo in futuro e ti daremo un'idea di ciò. E questo è in grado di anticipare davvero - o dovrei dire dinamicamente anticipare - le cose mentre stanno accadendo. Ora, nel caso dei report, una delle cose che abbiamo nello strumento sono tre diversi report di previsione. E nel caso, ad esempio, di una previsione del database, cosa probabilmente farei nella situazione di poter anticipare le dimensioni di un database per un periodo di tempo, e Ill ti fornirà solo un paio di esempi. Quindi, prenderò il mio database di controllo, che è piuttosto intensivo per l'I / O - ci sono molti dati che vanno su di esso. Abbiamo, vediamo, bene, facciamo questo qui e prendiamo semplicemente il database sanitario qui.
Ma il punto è che non vedo solo lo spazio su questo, sono in grado di dire "Guarda, prendiamo i dati degli ultimi anni di dati" - e sto andando qui un po ', non ho davvero un anno valore di dati, ho circa due mesi di dati - ma, poiché sto scegliendo una frequenza di campionamento di mesi qui, sarò in grado di anticipare o prevedere in questo caso le prossime 36 unità perché la nostra frequenza di campionamento è impostata su mesi - questa è un'unità, è un mese - e poi sarei in grado di eseguire un rapporto per mostrarmi sostanzialmente dove potremmo anticipare la nostra crescita futura, per questi tre database. E possiamo vedere che abbiamo un diverso grado di differenza, o varianza, tra i tre diversi database, in particolare per la quantità di dati che stanno consumando storicamente.
Possiamo vedere che i punti dati qui rappresentano i dati storici, e quindi le linee che ci forniranno la previsione, insieme ai numeri per sostenerlo. Quindi possiamo farlo a livello di tavolo, possiamo farlo anche a livello di unità, dove posso prevedere quanto grandi saranno le mie unità, compresi i punti di montaggio. Saremo in grado di prevedere questo stesso tipo di informazioni, ma ancora una volta, a seconda della frequenza di campionamento, mi permetterà di determinare quante unità e dove stavano prendendo ciò che vogliamo prevedere. Si noti inoltre che abbiamo diversi tipi di tipo di previsione. In questo modo avrai molte opzioni e flessibilità quando arriva il momento di fare le previsioni. Ora, è una cosa che fa bene, nel darti una data specifica e poter dire "Ehi in questa data, è qui che anticiperemmo la crescita dei tuoi dati". Oltre a ciò, tuttavia, possiamo fornirti con altre informazioni correlate ad alcune delle analisi che eseguiamo durante le ore di inattività e al servizio durante l'esecuzione. Alcune delle cose che fa, è che tenta di anticipare le cose che probabilmente accadranno, basandosi sulla storia di quando le cose sono accadute in passato.
Quindi possiamo vedere qui, in realtà, una previsione ci sta fornendo alcune intuizioni sulla probabilità che abbiamo problemi durante la serata sulla base di cose che sono successe ancora una volta in passato. Quindi, ovviamente, è fantastico, specialmente se non sono un DBA, posso guardare queste cose, ma cosa c'è di meglio se non sono un DBA, è questa scheda di analisi. Quindi, prima che questo fosse qui nello strumento che avremmo esaminato e mostrato il prodotto alle persone e loro sarebbero "È fantastico, vedo tutti questi numeri, vedo tutto, ma non so cosa fare" (ride) "come di conseguenza. ”E quindi quello che abbiamo qui è un modo migliore per te di essere in grado di capire, se ho intenzione di agire per aiutare con le prestazioni, se ho intenzione di agire per aiutare anche con la salute del mio ambiente, essere in grado di disporre di un modo classificato per fornire tali consigli, nonché utili suggerimenti nelle informazioni per saperne di più su tali consigli e avere effettivamente collegamenti esterni ad alcuni di quei dati, che mi mostreranno e mi porteranno ai motivi per cui queste raccomandazioni sono fatte.
E in molti casi, essere in grado di fornire uno script che automatizzerebbe, come ho già detto, la correzione di questi problemi. Ora, parte di ciò che stava facendo qui con questa analisi - e Ill ti mostrerò quando entro per configurare le proprietà di questa istanza, e vado nella sezione di configurazione dell'analisi - abbiamo molte categorie diverse che sono elencate qui, e parte di questo, abbiamo ottimizzazione dell'indice e ottimizzazione delle query. Quindi, stavano valutando non solo le metriche stesse e cose del genere, ma anche cose come i carichi di lavoro e gli indici. Nel caso qui, in realtà, facciamo qualche analisi analitica aggiuntiva sull'indice. Quindi, è una di quelle situazioni in cui non voglio, in molti casi, non voglio aggiungere un indice se non ne ho bisogno. Ma a un certo punto c'è una specie di punto di non ritorno, in cui dico: “Bene, la tabella sta arrivando alle dimensioni o ai tipi di query in esecuzione all'interno del carico di lavoro ha senso ora per aggiungere un indice. Ma non avrebbe avuto senso forse sei settimane prima. ”Quindi questo ti consente di ottenere in modo dinamico quella visione di cose che probabilmente, come ho detto, miglioreranno le prestazioni in base a ciò che accade nell'ambiente, a ciò che accade all'interno dei carichi di lavoro, e facendo quel genere di cose.
E così ottieni molte buone informazioni qui, così come la possibilità di ottimizzare queste cose automaticamente. Quindi, questa è un'altra area in cui saremo in grado di dare una mano, in termini di ciò che chiamiamo analisi predittiva. Ora, oltre a ciò, dovrei dire, abbiamo anche altre aree che penso si prestino ad aiutarvi a prendere decisioni. E quando parliamo di prendere decisioni, ancora una volta, essere in grado di guardare i dati storici, fornire alcune informazioni per portarci dove dobbiamo essere per migliorare tali prestazioni.
Ora, una delle cose che possiamo fare è avere un visualizzatore di base che ci consente di scegliere in modo selettivo qualunque metrica vorremmo - e di farmi trovare qui una decente - Sto andando all'utilizzo della CPU SQL, ma il punto è che puoi andare indietro per molte settimane per dipingere queste immagini per farti vedere quando sono i tuoi valori anomali, per vedere in generale dove cade quel valore nei periodi di tempo in cui abbiamo raccolto i dati. E poi, oltre a ciò, noterai anche che quando andiamo all'istanza vera e propria, abbiamo la possibilità di configurare le nostre basi. E le linee di base sono una parte davvero importante della capacità di automatizzare le cose e di poter essere informate delle cose. E la sfida, come direbbe la maggior parte dei DBA, è che il tuo ambiente non funziona sempre allo stesso modo, nel corso della giornata, rispetto alla sera e quant'altro, come menzionato in precedenza nell'esempio con i periodi di manutenzione, quando avere alti livelli di CPU o qualunque cosa possa accadere.
Quindi, nel caso qui, con queste linee di base effettive, possiamo avere più linee di base, quindi potrei avere una linea di base, ad esempio, durante le mie ore di manutenzione. Ma potrei altrettanto facilmente creare una base per le mie ore di produzione. E il punto di farlo è quando andiamo in un'istanza di SQL e in realtà abbiamo queste molteplici linee di base, quindi saremmo in grado di anticipare e di essere in grado di eseguire un tipo di automazione, un tipo di riparazione o solo un avviso in generale, diversamente specifico per quelle finestre del tempo. Quindi, una delle cose che vedrai qui, sono queste linee di base che generiamo stanno usando i dati storici per fornire quell'analisi, ma, cosa ancora più importante, posso cambiare queste soglie staticamente, ma posso anche automatizzare anche queste dinamicamente. Quindi, quando la finestra di manutenzione, o dovrei dire che la finestra della linea di base della manutenzione si alza, queste soglie passerebbero automaticamente specifiche ai carichi che sto incontrando durante quella finestra di tempo, rispetto forse a metà giornata quando i miei carichi non sono come molto, quando i carichi di lavoro non sono così impattanti.
Quindi, questo è qualcos'altro da tenere a mente, in termini di base. Ovviamente questi saranno davvero utili per te, in termini di comprensione anche di ciò che è normale e di essere in grado di capire, impegnarti quando stai per esaurire le risorse. Ora, l'altro tipo di cose che abbiamo nello strumento, che ti aiuterà a prendere decisioni, oltre al baselining e alla possibilità di impostare avvisi attorno a quelle baseline e alle soglie che crei dinamicamente, è come ho detto prima, solo essere in grado di eseguire una miriade di rapporti che mi aiutano a rispondere alle domande su cosa sta succedendo.
Quindi, ad esempio, se avessi 150 istanze che gestisco - nel mio caso non lo so, quindi dobbiamo giocare a questo finto gioco - ma se avessi tutte le mie istanze di produzione e avessi bisogno di capire dov'è l'area che Ho bisogno di attenzione, in altre parole, se avrò solo un tempo limitato per eseguire un qualche tipo di amministrazione per migliorare le prestazioni, voglio concentrarmi sulle aree chiave. E così, detto questo, sarei in grado di dire: "In base a quell'ambiente, posiziona le mie istanze l'una rispetto all'altra e dammi quella classifica per pipe di contesa". Quindi, sia che si tratti dell'utilizzo del disco, dell'utilizzo della memoria, sia che aspetti sia che sia il tempo di risposta, sono in grado di correlare - o dovrei dire rango - quelle istanze l'una contro l'altra. Ovviamente l'istanza che si trova in cima a ogni lista, se è la stessa istanza, è probabilmente qualcosa su cui voglio davvero concentrarmi, perché è ovviamente ancora una volta in cima alla lista.
Quindi, hai molti report nello strumento che ti aiutano in termini di classificazione dell'ambiente a livello di istanza; puoi farlo anche a livello di database, dove posso mettere i miei database uno contro l'altro. In particolare per le soglie e le aree che posso impostare, posso anche impostare caratteri jolly qui, se voglio, per concentrarmi solo su database particolari, ma il punto è che posso confrontare i miei database nello stesso modo. Inoltre, per quanto riguarda altri tipi di analisi comparativa e quella grande in questo strumento, è l'analisi di base che abbiamo. Quindi, se scorri verso il basso fino alla visualizzazione del servizio qui, vedrai che esiste un rapporto sulle statistiche di base. Ora questo rapporto ovviamente ci aiuterà a capire non solo quali sono i valori delle metriche, ma per un'istanza specifica potrei uscire e, per ognuna di queste metriche, essere in grado di guardare effettivamente le linee di base per queste metriche.
Quindi, qualunque cosa sia, come percentuale o qualunque cosa io possa uscire e dire: "Vediamo la linea di base per questo scoppiato negli ultimi 30 giorni", nel qual caso mi mostrerà i valori effettivi rispetto alla linea di base e Sarei in grado di prendere alcune decisioni usando quelle informazioni, ovviamente, quindi questa è una di quelle situazioni, in cui dipenderà da quale domanda si sta ponendo in quel momento. Ma questo ovviamente ti aiuterà per molte di queste domande. Vorrei poter dire che abbiamo avuto un rapporto che fa tutto, ed è un po 'come il rapporto facile, in cui si preme e si preme il pulsante e risponde a tutte le domande "what if" a cui si possa mai rispondere. Ma la realtà è che avrai molti attributi e molte opzioni tra cui scegliere in questi pull-down per poter formulare quelle domande "what if" che stai cercando.
Quindi molti di questi rapporti sono orientati alla capacità di rispondere a questi tipi di domande. E quindi, è molto importante anche che questi report e, in aggiunta, tutte le cose che ti abbiamo già mostrato nello strumento, come ho detto prima, abbiano la flessibilità di incorporare nuove metriche, di essere gestite, anche di poter creare contatori, o query SQL che sono incorporate nei tuoi intervalli di polling, per essere in grado di aiutarmi a rispondere a queste domande, che forse non abbiamo previsto di monitorare immediatamente, è possibile aggiungere quella roba. E sarai quindi in grado di fare tutte le stesse cose che ti ho appena mostrato: baseline, eseguire report e creare report da quella metrica, e poter rispondere e fare molti di questi diversi tipi di cose che ti sto mostrando qui.
Ora, oltre a ciò - e una delle cose che abbiamo incontrato di recente ultimamente - è stato il primo, tutti che lanciavano o passavano alle macchine virtuali. E ora abbiamo un sacco di persone che si stanno dirigendo verso il cloud. E ci sono molte domande che sorgono intorno a quel tipo di cose. Ha senso per me passare al cloud? Risparmierò trasferendomi nel cloud? Se dovessi mettere queste cose su una macchina virtuale, su una macchina con risorse condivise, quanti soldi posso risparmiare? Quei tipi di domande, ovviamente, sorgeranno anche. Quindi, molte di queste cose da tenere a mente, con Diagnostic Manager, possiamo aggiungere e estrarre dagli ambienti virtualizzati di VMware e Hyper-V. Possiamo anche aggiungere istanze che sono disponibili sul cloud, quindi i tuoi ambienti come Azure DB, ad esempio, o anche RDS, possiamo estrarre metriche anche da quegli ambienti.
Quindi c'è molta flessibilità e molta capacità di rispondere a quelle domande in quanto si riferisce a quegli altri tipi di ambienti in cui vediamo le persone andare verso. E ci sono ancora molte domande su questa roba, e poiché vediamo che le persone che consolidano quegli ambienti avranno bisogno di essere in grado di rispondere anche a quelle domande. Quindi, questa è una panoramica abbastanza buona, ad esempio, di Diagnostic Manager, in quanto si riferisce a questo argomento. So che il tema della business intelligence è emerso e abbiamo anche uno strumento di business intelligence di cui non abbiamo parlato oggi, ma ti fornirà anche informazioni in merito alla risposta a questo tipo di domande in relazione ai tuoi cubi e anche tutti quei diversi tipi di cose. Ma si spera che questa sia stata una buona panoramica, almeno in termini di come questo prodotto può aiutare con la capacità di formulare un buon piano.
Eric Kavanagh: Va bene, roba buona. Sì, lo lancerò a Rick, se è ancora là fuori. Rick, hai qualche domanda da te?
Rick Sherman: Sì, quindi prima di tutto, è fantastico, mi piace. Mi piace in particolare l'estensione a VM e cloud. Vedo molti sviluppatori di app pensare che se è nel cloud, non hanno bisogno di sintonizzarlo. Così-
Bullett Manale: Giusto, dobbiamo ancora pagare per questo, giusto? Devi ancora pagare per qualunque cosa le persone stiano mettendo sul cloud, quindi se funziona male o se sta causando molti cicli della CPU, è più denaro che devi pagare, quindi no, devi ancora misurare questa roba, assolutamente.
Rick Sherman: Sì, ho visto molti progetti scadenti nel cloud. Volevo chiedere, sarebbe utilizzato anche questo prodotto - so che hai menzionato il prodotto BI e hai tonnellate di altri prodotti che interagiscono tra loro - ma inizieresti a guardare le prestazioni SQL, le singole query in questo strumento? O sarebbero altri strumenti che verrebbero utilizzati per questo?
Bullett Manale: No, questo sarebbe assolutamente. Questa è una delle cose che non ho trattato e volevo dire, è la parte delle domande. Esistono molti modi diversi per identificare le prestazioni delle query, indipendentemente dal fatto che siano correlate, in particolare per le attese come vediamo in questa vista qui, o se sono correlate al consumo di risorse delle query in generale, esiste un numero intero di modi in cui possiamo analizzare le query prestazione. Indipendentemente dalla sua durata, CPU, I / O e, ancora una volta, possiamo anche esaminare i carichi di lavoro stessi per fornire alcune informazioni. Possiamo fornire i consigli nella sezione di analisi e abbiamo anche una versione basata sul Web che fornisce informazioni sulle query stesse. Quindi posso ottenere consigli sugli indici mancanti e la possibilità di visualizzare il piano di esecuzione e tutto quel genere di cose; è anche una capacità. Quindi, in assoluto, possiamo diagnosticare le query in sette modi a domenica (ride) ed essere in grado di fornire tale intuizione in termini di numero di esecuzioni, che si tratti di consumo di risorse, attese, durata, tutta quella roba buona.
Rick Sherman: Ok fantastico. E poi qual è il carico sulle istanze stesse con tutto questo monitoraggio?
Bullett Manale: È una buona domanda. La sfida nel rispondere a questa domanda è, dipende, è come qualsiasi altra cosa. Molto di ciò che il nostro strumento ha da offrire, offre flessibilità e parte di quella flessibilità è che puoi dirgli cosa raccogliere e cosa non raccogliere. Quindi, ad esempio, con le domande stesse, non devo raccogliere le informazioni di attesa, oppure posso. Sono in grado di raccogliere informazioni relative a query che superano un periodo di tempo, di esecuzione. A titolo di esempio, se dovessi andare a configurare il monitor delle query e dovessi dire "Consente di cambiare questo valore a zero", la realtà è che fondamentalmente lo strumento raccoglie tutte le query che vengono eseguite e che in realtà non è il spirito del perché è lì, ma in generale se volessi fornire un campione completo di dati per tutte le domande, potrei farlo.
Quindi, è molto relativo a quali sono le tue impostazioni, generalmente parlando, fuori dalla scatola. È ovunque da circa l'1–3 percento di spese generali, ma ci saranno altre condizioni che verranno applicate. Dipende anche da quante query di porte sono in esecuzione nel tuo ambiente, giusto? Dipende anche dal metodo di raccolta di tali query e dalla versione di SQL. Quindi, ad esempio, SQL Server 2005, non sarebbe stato in grado di estrarre da eventi estesi, mentre in questo modo trarremmo traccia da una traccia. Quindi, sarebbe un po 'diverso in termini di come faremmo per raccogliere quei dati, ma ciò ha detto, come ho detto, che siamo stati in giro per immagino dal 2004 con questo prodotto. È passato molto tempo, abbiamo ottenuto migliaia di clienti, quindi l'ultima cosa che vogliamo fare è avere uno strumento di monitoraggio delle prestazioni che causa problemi di prestazioni (risate). Quindi cerchiamo di evitarlo il più possibile, ma in generale, in questo modo circa l'1–3 percento è una buona regola empirica.
Rick Sherman: OK, e questo è abbastanza basso, quindi è fantastico.
Eric Kavanagh: Buono. Robin, hai qualche domanda da te?
Robin Bloor: Mi dispiace, ero in sordina. Hai una capacità multipla di database, e sono interessato a come puoi esaminare più database e quindi puoi sapere che una base di risorse più ampia è probabilmente suddivisa tra varie macchine virtuali e così via. Sono interessato a come le persone lo usano davvero. Sono interessato a ciò che i clienti stanno facendo con quello. Perché questo mi sembra, beh, certamente, quando stavo scherzando con i database, qualcosa che non avevo mai avuto a portata di mano. E prenderei in considerazione solo un'istanza in qualsiasi modo significativo in un dato momento. Quindi, come lo usano le persone?
Bullett Manale: In generale, stai parlando in generale solo dello strumento stesso? Come lo usano? Intendo, in generale, si tratta di poter avere un punto centrale di presenza dell'ambiente. Avere tranquillità e sapere che se fissano uno schermo e vedono il verde, sanno che tutto è buono. È quando si verificano problemi e ovviamente la maggior parte dei casi dal punto di vista dei DBA, molte volte si verificano quando si trovano davanti alla console, quindi essere in grado di essere avvisati non appena si verifica il problema. Ma oltre a ciò, essere in grado di capire quando si verifica il problema, essere in grado di arrivare al cuore delle informazioni che li stanno fornendo in termini di perché sta accadendo. E questo è, penso, la parte più grande: essere proattivi al riguardo, non essere reattivi.
La maggior parte dei DBA con cui parlo - e non lo so, è una buona percentuale di questi - sfortunatamente sono ancora nel tipo reattivo di ambiente; aspettano che un consumatore si avvicini a loro per dire loro che c'è un problema. E così, vediamo molte persone che cercano di staccarsi da quello e penso che questa sia una grande parte del motivo per cui le persone come questo strumento sono che li aiuta a essere proattivi ma fornisce anche loro la visione di ciò che sta succedendo , qual è il problema, ma in molti casi, quello che troviamo almeno - e forse sono solo i DBA a dirci questo - ma i DBA, la percezione è sempre il loro problema, anche se è lo sviluppatore dell'applicazione che ha scritto l'applicazione che non l'hanno scritta correttamente, sono quelli che si prenderanno la colpa, perché stanno portando quell'applicazione nei loro sistemi o server e poi quando le prestazioni sono cattive, tutti puntano al DBA che dice: "Ehi, è colpa tua."
Quindi, questo strumento verrà utilizzato molte volte per aiutare il DBA a dire: "Ehi, è qui che si trova il problema e non sono io". (Ride) Dobbiamo migliorare questo, che si tratti di modificare le query o qualunque cosa possa essere. In alcuni casi cadrà nel loro secchio in termini di responsabilità, ma almeno avere lo strumento per essere in grado di aiutarli a capirlo e saperlo, e farlo in modo tempestivo è ovviamente l'approccio ideale.
Robin Bloor: Sì, la maggior parte dei siti con cui ho familiarità, ma è passato un po 'di tempo da quando sono stato là fuori, a guardare vari siti multi-database, ma soprattutto quello che ero solito trovare era che ci sarebbero stati DBA focalizzati su una manciata di banche dati. E quelli sarebbero i database, che se mai dovessero andare giù, sarebbe un vero grosso problema per l'azienda, e così via e così via. E gli altri, raccoglieranno statistiche di tanto in tanto per vedere che non hanno esaurito lo spazio e non li hanno mai guardati affatto. E mentre stavi facendo la demo, stavo guardando questo e stavo pensando bene, in un modo o nell'altro, che estendi, semplicemente fornendo qualcosa del genere per database che spesso non interessano a nessuno, perché hanno una crescita dei dati , a volte hanno anche una crescita delle applicazioni. Stai estendendo la copertura DBA in modo abbastanza drammatico. Quindi, ecco di cosa si tratta in realtà, è che con un set di strumenti come questo, riesci a fornire un servizio DBA praticamente a tutti i database che si trovano nella rete aziendale?
Bullett Manale: Certo, voglio dire, la sfida è che, come hai detto abbastanza eloquentemente, è come se ci fossero alcuni database a cui i DBA tengono e poi altri a cui non importa così tanto. E il modo in cui questo particolare prodotto, il modo in cui è concesso in licenza è per ogni istanza. Quindi, suppongo che tu abbia detto, una soglia di quando le persone decidono "Ehi, questa non è un'istanza abbastanza critica che voglio gestirla con questo strumento". Detto questo, ci sono altri strumenti che abbiamo che sono più , Immagino, approvvigionando a quei casi meno importanti di SQL. Uno di questi sarebbe come il Gestore inventario, dove eseguiamo leggeri controlli di integrità rispetto alle istanze, ma in aggiunta a ciò che facciamo è fare scoperte, quindi identifichiamo nuove istanze che sono state portate online e quindi, da quel punto, come DBA posso dire: "OK, ecco una nuova istanza di SQL, ora è Express? È la versione gratuita o è una versione aziendale? ”Probabilmente è una domanda che vorrei farmi, ma in secondo luogo, quanto è importante per me quell'istanza? Se non fosse così importante, potrei avere questo strumento uscente e farlo, generico, ciò che definirei controlli di salute generici, nel senso che sono i tipi elementari di cose a cui tengo come DBA: l'unità si sta riempiendo? Il server risponde ai problemi? Le cose principali, giusto?
Considerando che con Diagnostic Manager, lo strumento che ti stavo mostrando, scenderà a livello di query, scenderà nella raccomandazione degli indici, esaminando il piano di esecuzione e tutta quella roba buona, mentre questo è principalmente focalizzato su chi possiede cosa, cosa è che possiedo e chi ne è responsabile? Quali service pack e hot fix ho? E i miei server funzionano con gli ingredienti principali di quella che considererei un'istanza sana di SQL? Quindi, per rispondere alla tua domanda, c'è un po 'di confusione. Quando abbiamo persone che guardano questo strumento, in genere stanno guardando un insieme più critico di istanze. Detto questo, abbiamo alcune persone che acquistano ogni istanza che hanno e lo gestiscono, quindi dipende solo. Ma ti dico, nel complesso, c'è sicuramente una soglia di quelle persone che considerano il loro ambiente abbastanza importante da avere uno strumento come questo per gestire quelle istanze.
Robin Bloor: Ok, un'altra domanda prima di consegnarla a Eric. L'impressione che si ottiene, osservando il settore è che i database hanno ancora una vita, ma tutti i dati si riversano in tutti questi laghi di dati e così via e così via. Questo è l'hype, davvero, e l'hype non riflette mai la realtà, quindi sono interessato a quale tipo di realtà stai percependo là fuori? I database importanti all'interno di un'organizzazione stanno vivendo la tradizionale crescita dei dati, che pensavo al 10 percento all'anno? O stanno crescendo di più? I big data fanno gonfiare questi database? Qual è l'immagine che vedi?
Bullett Manale: Penso che molti casi abbiano visto spostare alcuni dei dati in quegli altri segmenti in cui ha più senso, quando ci sono altre tecnologie che sono disponibili. Recentemente, alcuni dei dati più grandi. Ma questi database, direi, è difficile generalizzare in molti casi perché tutti sono un po 'diversi. In generale, però, vedo alcune divergenze. Vedo, come ho detto, le persone si stanno spostando verso i modelli elastici in molti casi, perché vogliono aumentare le risorse e non così tanto in altre aree. Alcune persone stanno passando ai big data. Ma è difficile farsi un'idea, diciamo, della percezione, perché in generale le persone con cui sto parlando hanno i database tradizionali e lo stanno usando in un ambiente SQL Server.
Detto questo, direi in termini di SQL stesso, sicuramente penso ancora che stia guadagnando quote di mercato. E penso che ci siano molte persone che si stanno ancora dirigendo verso SQL da altri luoghi come Oracle, perché è più conveniente e sembra essere evidente, man mano che le versioni di SQL diventano più avanzate - e lo vedi con le cose più recenti che stanno succedendo avanti con SQL, in termini di crittografia e di tutte le altre funzionalità che lo rendono un ambiente o una piattaforma di database - questo è ovviamente molto mission-critical, immagino. Quindi, penso che stessero vedendo anche quello. Dove stai vedendo un cambiamento, sta ancora accadendo. Voglio dire, stava succedendo 10 anni fa, è ancora, penso, in termini di SQL Server, in cui gli ambienti crescono e la quota di mercato sta crescendo.
Robin Bloor: OK, Eric, presumo che il pubblico abbia una domanda o due?
Eric Kavanagh: Sì, lascia che te ne dia uno veloce. È una domanda piuttosto buona, in realtà. Uno dei partecipanti chiede: questo strumento può dirmi se una tabella potrebbe aver bisogno di un indice per accelerare la query? In tal caso, puoi mostrare un esempio?
Bullett Manale: Sì, quindi non so se ne ho uno per l'aggiunta specifica di un indice, ma puoi vedere qui, abbiamo consigli sulla frammentazione qui. Credo anche che l'abbiamo appena fatto e questo faceva parte del Diagnostic Manager che offre la versione basata sul web, dove mi dice che ho un indice mancante. E possiamo visualizzare questi consigli e ci dirà il potenziale guadagno di ciò indicizzando tali informazioni. L'altra cosa che dovrei solo menzionare è che quando facciamo le raccomandazioni, per molti di questi, la sceneggiatura sarà costruita per questo. Quello non è un buon esempio, ma potresti vedere, sì, le situazioni in cui un indice - un indice duplicato o l'aggiunta di un indice - migliorerebbe le prestazioni e, come ho detto prima, facciamo molto quello attraverso un'ipotetica analisi dell'indice. Quindi, aiuta davvero in termini di comprensione del carico di lavoro, essere in grado di applicarlo alla raccomandazione.
Eric Kavanagh: Questa è roba fantastica, e questo mi darà un buon seguito ai commenti finali qui. Anche Robin, io e Rick, abbiamo sentito da molti anni, si parla di database di auto-tuning. È un database auto-tuning! Tutto quello che posso dirti è: non crederci.
Bullett Manale: Non credere all'hype.
Eric Kavanagh: Potrebbero esserci alcune piccole cose che vengono fatte in modo dinamico, ma anche quello, potresti voler verificarlo e assicurarti che non stia facendo qualcosa che non vuoi che faccia. Quindi, per un bel po 'di tempo, avremmo avuto bisogno di strumenti come questo per capire cosa stava succedendo a livello di database e, come diceva Robin, i data lake sono concetti affascinanti, ma probabilmente c'è la stessa possibilità che prendano il controllo di quanti ce ne siano un mostro di Loch Ness in qualunque momento presto. Quindi, direi di nuovo, il mondo reale ha molta tecnologia di database, abbiamo bisogno di persone, DBA, per guardare queste cose e sintetizzarle. Puoi dirlo, devi sapere cosa stai facendo per far funzionare queste cose. Ma hai bisogno degli strumenti per darti le informazioni per sapere cosa stai facendo. Quindi, la linea di fondo è che i DBA stanno andando bene.
E grazie mille a Bullett Manale e ai nostri amici di IDERA. E, naturalmente, Rick Sherman e Robin Bloor. Archiviamo tutti questi webcast, quindi saltate online insideanalysis.com o sul nostro sito partner www.techopedia.com per ulteriori informazioni su tutto ciò.
E con quello, beh, arrivederci, gente. Grazie ancora, ci sentiamo la prossima volta. Stai attento. Ciao ciao.