SQL Server: Utilizzo di oggetti di gestione dinamica
Gli oggetti DMO (Dynamic Management Objects) consentono di gestire e monitorare i dettagli relativi al carico di lavoro in SQL Server, aspetto essenziale per l'ottimizzazione delle prestazioni.
Tratte da "SQL Server DMV Starter Pack," pubblicato dalla documentazione di Red Gate (2010).
Glenn bacche, Louis Davidson e Tim Ford
Dynamic Management Objects (DMO) sono un insieme di oggetti SQL Server memorizzati nello schema di sistema. Essi forniscono una finestra nelle attività viene eseguita su diverse istanze di SQL Server e le risorse che utilizzano queste attività.
In altre parole, DMO espone informazioni utili riguardanti le connessioni, sessioni, transazioni, le istruzioni di SQL e i processi in esecuzione su un'istanza di database, il carico di lavoro risultante generato sul server, come viene distribuito, dove i punti di pressione e così via. Avente rivelato un collo di bottiglia particolare o un punto di pressione, si può quindi misure necessarie per l'inconveniente, ad esempio aggiungendo un indice per l'ottimizzazione di una query o all'abbattimento semplicemente una sessione di blocco.
Il termine "dinamico" si riferisce al fatto che le informazioni memorizzate in DMO generate dinamicamente da una vasta gamma di punti di strumentazione. Si tratta di strutture in memoria in tutto il motore di SQL Server. Questi dati viene quindi esposto in forma tabellare nello schema del database sys. I dati vengono esposti nelle visualizzazioni, nel qual caso essi sta denominati viste a gestione dinamica (DMV) o nelle funzioni di valori di tabella, nel qual caso essi sta detta le funzioni di gestione dinamica (DMF).
DMV e DMF sono sostanzialmente le viste di sistema e le funzioni di sistema. Utilizzarli come se fossero qualsiasi altra vista o funzione all'interno di SQL Server: query su essi, join, il passaggio di parametri e infine restituire un unico risultato set contenente i dati necessari per analizzare un particolare problema riguardanti lo stato o la salute dell'istanza SQL Server.
DMV per l'ottimizzazione delle prestazioni
DMO espone una matrice a volte dizzying delle informazioni. La visualizzazione originale del sistema sysprocesses essenzialmente è stata denormalizzazione e è stati aggiunti molti nuovi DMO. Molte nuove colonne di dati sono ora disponibili per le query. Il motore di database diventa meglio gestiti con strumenti, la quantità di dati disponibili sul modulo di gestione e le operazioni eseguite, continuerà a crescere.
Anche la complessità di cucitura tra loro i dati da una matrice di tipo diverso di DMO, abbinata alla scelte inizialmente sconcertante delle colonne dove esposti, ha portare alcuni amministratori di database per liken l'esecuzione di query DMO per la raccolta dirompenti Mistero..
Tuttavia, il processo la normalizzazione è, in molti modi, reso i dati che restituiscono molto più facile da analizzare e capire DMO. Quando si inizia a scrivere script personalizzati, vedrai i trucchi stessi e i motivi di join simili, utilizzati tempi. Di conseguenza, una serie di script di base relativamente piccola può essere facilmente adattata a molti requisiti.
Per alcuni aspetti, lavorando attraverso DMO per i dati di diagnostici è necessario un processo di sbucciatura livelli nascosti. Al livello esterno, ci possiamo sapere chi è collegato alla nostra istanze SQL Server e il modo in cui sono connessi; le sessioni in esecuzione su di essi; e vengono eseguite le richieste da queste sessioni. È possibile scoprire i dettagli delle istruzioni SQL viene eseguite da queste richieste, i piani di query vengono utilizzati per eseguirli e così via.
Eliminazione di un livello verso il basso, abbiamo il livello di transazione, nei casi in cui ci possiamo sapere di quali blocchi vengono mantenuti come risultato di queste transazioni, esaminare la possibilità di eventuali blocchi e così via. Lo spostamento verso un altro livello, è possibile ricavare come il carico di lavoro rappresentato dalle richieste presentate si traduce in lavoro effettivo del sistema operativo. È possibile determinare, ad esempio:
- Quali attività effettiva (threads) vengono eseguite allo scopo di soddisfare le richieste
- Il lavoro che si sta eseguendo in termini di utilizzo di memoria, CPU e i/O
- Come i/O viene distribuito tra i vari file
- Effetti dei thread lunghi spendere in attesa, non è possibile e per questo motivo
Ha il compito di riunire tutte le porzioni di dati da vari livelli diversi per fornire i risultati necessari per evidenziare i problemi specifici del sistema.
Punto nel tempo vs. Cumulativo
Come indicato, possiamo eseguire una query dati memorizzati nei DMO esattamente come si farebbe con qualsiasi altra tabella, visualizzazione o non funzioni. Tuttavia, ricordarsi che i dati che vengono visualizzati siano "" natura dinamici. Viene raccolto da una gamma di diverse strutture nel motore di database e rappresenta un punto-in-time "istantanea" dell'attività che si verificava sul server al momento che è stata eseguita la query DMO.
In alcuni casi, questo è esattamente quello desiderato. Hai un'efficienza di emettere e desideri conoscere le query in esecuzione sul server che potrebbero causare tale. In alcuni casi, tuttavia, può risultare abbastanza difficile interrogare i dati in questi DMO point-in-time nella speranza che il problema semplicemente "salterà è."
Se, ad esempio, si dispone di un problema di prestazioni verificare la presenza di eventuali schemi di blocco "inusuale" quindi è improbabile che un "select [colonne] from [blocco DMV]" indicherà la maggior parte, a meno che non si conosce molto bene il blocco "normale" è simile nel sistema e potranno facilmente individuare anomalie.
Tenere presente che i dati in un momento possono e probabilmente sarà cambia ogni volta che si query, come lo stato delle modifiche al server. Si dovrebbero aspettarsi occasionalmente risultati anomali o non rappresentativi e potrebbe essere necessario eseguire uno script più volte per avere un'idea dell'attività sull'istanza.
In altri casi, è cumulativi DMO. In altre parole, i dati in una colonna specifica sono cumulabile e incrementato ogni volta che si verifica un determinato evento. Ad esempio, ogni volta che una sessione attende un periodo di tempo per una risorsa venga resa disponibile, siano stati registrati in una colonna dell'os_wait_stats DMV. Durante l'esecuzione di query tali DMV, si vedrà, ad esempio, la quantità totale di tempo trascorsa in attesa per diverse risorse, in tutte le sessioni, poiché SQL Server è stato avviato o riavviato, a meno che una coerenza del database o DBCC, il comando è stato eseguito per cancellare manualmente le statistiche stored.
Mentre si otterrà un'ampia panoramica di dove tempo impiegato in attesa, un lungo periodo, renderà difficili da visualizzare i dettagli più piccoli. Se si desidera misurare l'impatto delle modifiche al database (un nuovo indice, ad esempio), è necessario eseguire una misurazione di base, apportare le modifiche e quindi misurare la differenza.
Infine, sempre tenere a mente che la maggior parte dei dati che vengono visualizzati in tale DMO è aggregare i dati raccolti attraverso un numero di sessioni, molte richieste e numerose transazioni. Il menzionato in precedenza wait_stats DMV, ad esempio, visualizzerà a un'istanza di livello nei casi in cui SQL Server speso dei tempi di attesa, aggregati in tutte le sessioni. Non è possibile verificare i tempi di attesa a livello di singola sessione, a meno che, ovviamente, si sta lavorando su un server isolato.
.png)
.png)
.png)
Glenn bacche lavora come architetto di database presso NewsGator Technologies in Denver, Colo. Egli è un MVP SQL Server e dispone di un'intera raccolta di certificazioni Microsoft, tra cui MCITP, MCDBA, MCSE, MCSD, MCAD e MCTS, che fornisca la prova che egli ama sostenere test.
Louis Davidson lavora nel settore IT da 16 anni come database aziendale, sviluppatore e architetto. Egli è stato SQL Server Microsoft MVP per sei anni e ha scritto quattro libri sulla progettazione di database. Egli è attualmente architetto di dati e a volte DBA per cognome la trasmissione di rete, gli uffici di supporto in Virginia Beach responsabile e Nashville, Tennessee
Timothy Ford è un MVP SQL Server e ha lavorato con SQL Server per più di dieci anni. È l'amministratore del database primario ed esperto in materia per la piattaforma di SQL Server per la salute dello spettro. Egli è stato scrittura sulla tecnologia dal 2007 per una vasta gamma di siti Web e si mantiene il proprio blog al thesqlagentman.com, che coprono SQL come argomenti di sviluppo ben come telecommuting e professionale.
Per ulteriori informazioni su "SQL Server DMV Starter Pack" nel red-gate.com/our-company/about/book-store.