INF: Ottimizzazione delle prestazioni di Microsoft SQL Server

Traduzione articoli Traduzione articoli
Identificativo articolo: 110352 - Visualizza i prodotti a cui si riferisce l?articolo.
Espandi tutto | Chiudi tutto

In questa pagina

Sommario

Al fine di ottimizzare le prestazioni di Microsoft SQL Server, è necessario innanzitutto identificare all'interno di un'ampia serie di situazioni quelle aree in grado di garantire un maggior aumento di prestazioni focalizzando su di esse la propria analisi,. in modo da evitare di dedicare tempo e sforzi ad ambiti in cui non sia possibile conseguire miglioramenti significativi.

Le informazioni riportate in questo articolo non fanno riferimento alle problematiche di prestazioni legate all'utilizzo concorrente di risorse da parte di più utenti. Questo è un argomento separato e complesso coperto nel documento "Maximizing Database Consistency and Concurrency," disponibile in SQL Server versione 4.2 x "Programmer Reference for C," Appendice E e anche in altri articoli della Knowledge Base. Non è la documentazione della versione 6.0, ma sono disponibili nel CD di MSDN (Microsoft Developer Network) in tale titolo.

In questo articolo non verrà presentata una discussione teorica sull'ottimizzazione delle prestazioni di SQL Server, bensì verranno prese in considerazione principalmente quelle aree che nel corso della loro lunga esperienza gli addetti del Servizio Supporto Tecnico di Microsoft SQL Server hanno identificato come in grado di garantire miglioramenti sostanziali di prestazioni in situazioni reali.

L'esperienza mostra infatti come sia possibile ottenere i miglioramenti più significativi in termini di prestazioni di SQL Server nelle aree della progettazione di database, di indici, di query e di applicazioni. Sono infatti le carenze in questi ambiti a causare spesso i principali problemi di prestazioni. Se pertanto si è interessati a migliorare le prestazioni, si consiglia innanzitutto di concentrare la propria attenzione su queste aree, in cui è possibile ottenere miglioramenti significativi a fronte di investimenti di tempo relativamente contenuti.

Sebbene altri aspetti a livello di sistema operativo, quali memoria, buffer di cache, hardware e così via siano sicuri canditati per uno studio delle prestazioni, l'esperienza dimostra che i miglioramenti ottenibili in queste aree sono spesso di natura incrementale. SQL Server gestisce automaticamente le risorse hardware disponibili riducendo l'esigenza e di conseguenza il vantaggio di un intervento manuale massiccio a livello di sistema.

Microsoft SQL Server 6.0 fornisce nuove opportunità per ottimizzare le prestazioni a livello di piattaforma globale garantendo notevoli miglioramenti in termini di memoria, di multiprocessing simmetrico, di analisi in parallelo dei dati, miglioramenti dell'utilità di ottimizzazione e striping del disco. Tuttavia, per quanto significativi questi miglioramenti possano essere, il loro ambito è comunque limitato,. dato che anche il computer più veloce può essere messo in ginocchio da query inefficienti o da applicazioni mal progettate. Per questa ragione, nonostante l'aumento di prestazioni consentito da SQL Server 6.0, è fondamentale ottimizzare l'aspetto della progettazione del database, degli indici, delle query e delle applicazioni.

La maggior parte dei problemi non può essere risolta con successo focalizzando la propria attenzione esclusivamente sul lato server. Il server infatti non è altro che un "servitore" del client, il quale invece detiene il pieno controllo sulle query inviate e di conseguenza sui blocchi acquisiti e rilasciati. Sebbene sia comunque possibile una messa a punto delle prestazioni sul lato server, la soluzione dei problemi di prestazioni dipende solitamente dalla capacità di riconoscere il ruolo dominante che il client svolge in questo tipo di problemi e nell'analizzare il comportamento dell'applicazione client.

Informazioni

Di seguito sono riportati alcuni suggerimenti che, in base ai si verifichi, ha fruttato notevole miglioramento delle prestazioni:

Normalizzare la progettazione del database logico

Una normalizzazione adeguata della progettazione del database logico è in grado di garantire migliori prestazioni. Oggi un database normalizzato dispone solitamente di molte tabelle con un numero ridotto di colonne,. mentre poche tabelle con molte colonne ciascuna è caratteristico di un database denormalizzato. Un database estremamente normalizzato è solitamente associato a complessi join relazionali, che possono avere un impatto negativo sulle prestazioni. Tuttavia l'utilità di ottimizzazione di SQL Server è molto efficiente nel selezionare join efficienti e rapidi se sono disponibili indici efficaci.

I vantaggi della normalizzazione includono:
  • Accelerazione dell'ordinamento e della creazione di indici, vista la presenza di tabelle con un numero ridotto di colonne.
  • Possibilità di consentire più indici raggruppati, in virtù del numero superiore di tabelle.
  • Indici con un numero inferiore colonne e pertanto più compatti.
  • Numero inferiore di indici per tabella, con conseguenti miglioramenti delle prestazioni delle operazioni di aggiornamento.
  • Meno valori NULL e meno dati ridondanti, aumentando in tal modo la compattezza del database.
  • Riduzione dell'impatto della concorrenza delle diagnostiche DBCC, in quanto i blocchi delle tabelle necessari interesseranno un numero inferiore di dati.
Con SQL Server una normalizzazione adeguata si rivela vantaggiosa anziché controproducente per le prestazioni. Aumenta di normalizzazione, così come il numero e la complessità dei join necessari per recuperare i dati. Come regola generale Microsoft suggerisce di eseguire il processo di normalizzazione a meno che questo non porti a un numero elevato di query con join a quattro o più vie.

Se la progettazione del database logico fosse già stata eseguita e non fosse possibile riprogettare completamente il database, potrebbe essere possibile normalizzare selettivamente una tabella di grandi dimensioni qualora l'analisi mostrasse un collo di bottiglia in tale tabella. Se l'accesso al database avviene tramite stored procedure, questa modifica dello schema potrebbe avere luogo senza alcun impatto sulle applicazioni. In caso contrario, sarebbe possibile nascondere la modifica creando una vista che abbia l'aspetto di una singola tabella.

Progettazione efficiente degli indici

A differenza di molti sistemi non relazionali, gli indici relazionali non fanno parte della progettazione del database logico. Gli indici possono infatti essere rimossi, aggiunti e modificati senza che ciò influisca sullo schema di database o sulla progettazione delle applicazioni in alcun modo se non in termini di prestazioni. Una progettazione efficiente degli indici è il presupposto per ottenere buone prestazioni di SQL Server. Per questi motivi, non deve esitare sperimentare indici diversi.

L'utilità di ottimizzazione sceglie solitamente l'indice più efficiente. La strategia generale di progettazione degli indici dovrebbe essere quella di fornire una buona selezione di indici all'utilità di ottimizzazione lasciando quindi all'utilità la responsabilità di assumere la decisione migliore. Questo consentirà di ridurre il tempo di analisi e offrirà buone prestazioni in situazioni molto diverse.

Di seguito sono riportati alcuni consigli per la progettazione degli indici:
  • Esaminare la clausola WHERE della query SQL, poiché questo è l'obiettivo principale di query optimizer.

    Ogni colonna elencata nella proposizione WHERE è un possibile candidato per un indice. Se si dispone di troppe query per esaminare, scegliere un insieme rappresentativo o solo quelli lenti. Se lo strumento di sviluppo genera in maniera trasparente codice SQL, ciò risulterà più difficile. Molti strumenti di sviluppo consentono invece di registrare in un file o sullo schermo la sintassi SQL generata per motivi di debugging. Si consiglia di utilizzare uno strumento che disponga di questa funzione.
  • Utilizzare indici con un numero ridotto di colonne.

    Gli indici con poche colonne sono spesso più efficaci rispetto agli indici composti a più colonne,. in quanto dispongono di più righe per pagina e di meno livelli di indici.

    L'utilità di ottimizzazione è in grado di analizzare efficacemente centinaia o persino migliaia di possibilità di indici e join. In presenza di molti indici a poche colonne le prestazioni migliorano in quanto vengono offerte maggiori possibilità di scelta all'utilità di ottimizzazione. Al contrario, in presenza di pochi indici con molte colonne l'utilità di ottimizzazione dispone di minori possibilità tra cui scegliere, il che può avere un impatto negativo sulle prestazioni.

    È spesso consigliabile non adottare la strategia di enfatizzare una query completamente coperta. È vero che, se tutte le colonne nella clausola SELECT sono coperte da un indice non cluster, l'utilità di ottimizzazione possono riconoscere questo e fornire buone prestazioni. Tuttavia questa situazione determina solitamente indici eccessivamente estesi e fa eccessivo affidamento sulla possibilità che l'utilità di ottimizzazione utilizzi questa strategia. In genere, è necessario utilizzare più numerosi indici stretti che spesso forniscono prestazioni migliori di una vasta gamma di query.

    Si consiglia di non creare più indici di quelli necessari per ottenere prestazioni di lettura adeguate a causa del sovraccarico di lavoro richiesto per l'aggiornamento di tali indici. Tuttavia anche le operazioni maggiormente orientate all'aggiornamento richiedono un numero superiore di operazioni di lettura rispetto a quelle di scrittura,. pertanto si consiglia di non esitare a provare un nuovo indice se si pensa che ciò possa essere di aiuto, sarà comunque sempre possibile rimuoverlo in seguito.
  • Utilizzare indici raggruppati.

    L'utilizzo appropriato di indici raggruppati può portare un notevole miglioramento nelle prestazioni. L'impiego di indici raggruppati è spesso in grado di accelerare le operazioni di UPDATE e DELETE, in quanto tali operazioni richiedono un notevole lavoro di lettura. È consentito un unico indice raggruppato per tabella, pertanto è consigliabile utilizzare tale indice in maniera assennata. Le query che restituiscono numerose righe o le query che coinvolgono un vasto intervallo di valori possono essere accelerate dall'impiego di un indice raggruppato.

    Esempi:
          SELECT * FROM PHONEBOOK
          WHERE LASTNAME='SMITH'
    
          -or-
    
          SELECT * FROM MEMBERTABLE
          WHERE  MEMBER_NO > 5000
           AND MEMBER_NO < 6000
    
    						
    Al contrario, le colonne del cognome o MEMBER_NO menzionate in precedenza probabilmente non sono ottimi candidati per un indice non cluster se il tipo di query è comune. Provare a utilizzare gli indici non cluster su colonne in cui vengono restituite alcune righe.
  • Esaminare l'univocità della colonna.

    Questo aiuta a decidere quale colonna è un buon candidato per un indice raggruppato o per un indice non raggruppato.

    Di seguito è riportato un esempio di query per l'analisi dell'univocità di una colonna:
          SELECT COUNT (DISTINCT COLNAME)
          FROM TABLENAME
    
    						
    Questa query ritorna il numero di valori univoci presenti nella colonna. Confrontare questo numero con il numero totale di righe presenti nella tabella. In una tabella 10.000 righe, 5.000 valori univoci renderebbe la colonna un ottimo candidato per un indice non cluster. Nella stessa tabella, 20 valori univoci rendono invece la colonna un ottimo candidato per un indice raggruppato. Tre valori univoci non dovrebbero invece essere indicizzati. Si tratta comunque solo di esempi e non di una regola infallibile. È bene ricordare di inserire gli indici nelle singole colonne elencate nelle proposizioni WHERE delle query.
  • Esaminare la distribuzione dei dati in colonne indicizzate.

    Spesso una query richiede un tempo di elaborazione particolarmente lungo in quanto è indicizzata una colonna con qualche valore univoco oppure in quanto in tale colonna viene eseguito un JOIN. Si tratta di un problema fondamentale dei dati e della query che non può essere solitamente risolto senza identificare questa situazione. Ad esempio, un elenco telefonico fisico in ordine alfabetico sul cognome non verrà accelerare la ricerca di una persona se tutti gli utenti nella città sono denominati semplicemente "Rossi" o "Bianchi". Oltre a query precedente, che fornisce una singola cifra per l'univocità della colonna, è possibile utilizzare una query GROUP BY per visualizzare la distribuzione di dati dei valori chiave indicizzati. Questo fornisce un'immagine a una risoluzione più elevata dei dati e una prospettiva migliore di come i dati vengono visualizzati dall'utilità di ottimizzazione.

    Di seguito è riportato un esempio di query per esaminare la distribuzione dei dati di valori chiavi indicizzati, presupponendo una chiave di due colonne in Col1, Col2:
          SELECT COL1, COL2, COUNT(*)
          FROM TABLENAME
          GROUP BY COL1, COL2
    
    						
    Questa query ritorna una riga per ciascun valore chiave, con un conteggio delle istanze di ciascun valore. Per ridurre il numero delle righe ritornate, potrebbe essere utile escludere alcune righe con una proposizione HAVING. Ad esempio la proposizione
          HAVING COUNT(*) > 1
    
    						
    escluderà tutte le righe che dispongono di una chiave univoca.

    Il numero delle righe ritornate in una query è un fattore importante nella selezione degli indici. L'utilità di ottimizzazione considera che un indice non raggruppato costi almeno un I/O di pagina per ogni riga ritornata. A questo ritmo diventa rapidamente più conveniente analizzare l'intera tabella. Questa è un'altra ragione per restringere la dimensione dell'insieme dei risultati o per trovare l'insieme maggiore di risultati utilizzando un indice raggruppato.
Non bisogna pensare sempre che l'impiego di indici significhi necessariamente buone prestazioni e viceversa. Se l'impiego di un indice ha sempre prodotto le prestazioni migliori, il compito dell'utilità di ottimizzazione sarà molto semplice, in quanto dovrà solo utilizzare qualsiasi indice disponibile. In realtà, la scelta sbagliata di recupero indicizzato può determinare prestazioni particolarmente modeste. Pertanto il compito dell'utilità di ottimizzazione sarà quello di selezionare il recupero indicizzato che sia in grado di aiutate le prestazioni ed evitare il recupero indicizzato dove ciò possa arrecare danno alle prestazioni.

Progettazione efficiente di query

Alcuni tipi di query prevedono l'impiego intensivo di risorse. Ciò è legato agli aspetti fondamentali dei database e degli indici comuni alla maggior parte dei sistemi di gestione dei database relazionali (RDMS) e non specificatamente a SQL Server. In realtà non si tratta di query inefficienti, in quanto l'utilità di ottimizzazione implementa le query nel modo più efficiente possibile,. bensì è la natura orientata agli insiemi di SQL a farle apparire inefficienti. Nessuna operazione di ottimizzazione potrà infatti eliminare il costo intrinseco di risorse imposto da questi costrutti. Sono intrinsecamente costose rispetto a una query più semplice. Sebbene SQL Server utilizzi il piano di accesso più ottimale, ciò sarà comunque limitato da quanto sostanzialmente possibile.

Ad esempio:
  • Grandi insiemi di risultati
  • Query IN, NOT IN e OR
  • Clausole WHERE altamente non univoche
  • Operatori di confronto != (diverso)
  • Certe funzioni colonna, quali SUM
  • Espressioni o conversioni di dati in proposizioni WHERE
  • Variabili locali in proposizioni WHERE
  • Viste complesse con GROUP BY
Vari fattori possono necessitare dell'impiego di alcuni di questi costrutti di query. L'impatto di tali costrutti verrà attenuato se l'utilità di ottimizzazione potrà restringere l'insieme dei risultati prima di applicare la porzione di query che richiede l'impiego intensivo di risorse. Di seguito sono riportati alcuni esempi.

Utilizzo intensivo di risorse:
   SELECT SUM(SALARY) FROM TABLE
				

Utilizzo meno intensivo di risorse:
   SELECT SUM(SALARY) FROM TABLE WHERE
   ZIP='98052'
				

Utilizzo intensivo di risorse:
   SELECT * FROM TABLE WHERE
   LNAME=@VAR
				

Utilizzo meno intensivo di risorse:
   SELECT * FROM TABLE
   WHERE LNAME=@VAR AND ZIP='98052'
				

Nel primo esempio, l'operazione SUM non può essere accelerata tramite l'impiego di un indice. Ciascuna riga deve essere letta e sommata. Supponendo che esista un indice nella colonna ZIP, l'utilità di ottimizzazione utilizzerà probabilmente questo indice per restringere l'insieme dei risultati prima di applicare l'operazione SUM. Ciò può essere molto più veloce.

Nel secondo esempio, la variabile locale non viene risolta fino al momento dell'esecuzione,. Tuttavia, l'ottimizzatore non può rimandare la scelta del piano di accesso solo in fase di esecuzione, è necessario scegliere in fase di compilazione. Eppure durante la compilazione, quando viene creato il piano di accesso, il valore di @VAR non è noto e di conseguenza non può essere utilizzato come input per indicizzare la selezione.

La tecnica illustrata prevede che venga ristretto l'insieme dei risultati attraverso l'uso di una proposizione AND. Come tecnica alternativa, utilizzare una stored procedure e passare il valore di @VAR come parametro alla stored procedure.

In alcuni casi anziché utilizzare una sola query complessa è consigliabile utilizzare un gruppo di query semplici che utilizzano tabelle temporanee per memorizzare i risultati intermedi.

Gli insiemi di risultati particolarmente numerosi sono costosi nella maggior parte dei RDBMS. È consigliabile non tentare di ritornare un ampio insieme di risultati al client per la selezione finale dei dati finale tramite ricerca. Risulta molto più efficiente per limitare le dimensioni del set di risultati, consentendo al sistema di database di eseguire la funzione a cui è destinato. Questo consente anche di ridurre il numero degli I/O di rete, rende l'applicazione più docile da implementare su collegamenti di comunicazione remoti lenti. e consente di migliorare le prestazioni legate alla concorrenza via via che l'applicazione viene scalata per un numero superiore di utenti.

Progettazione efficiente delle applicazioni

Non bisogna esagerare il ruolo svolto dalla progettazione delle applicazioni nelle prestazioni di SQL Server. Anziché considerare il server nel ruolo dominante è infatti più corretto vedere il client come entità di controllo e il server come servitore del client. SQL Server è completamente controllato dal client per quanto riguarda il tipo di query, i tempi di invio delle query e il modo in cui i risultati vengono elaborati. Ciò a sua volta ha un notevole impatto sul tipo e sulla durata dei blocchi, sul carico di I/O e della CPU sul server e di conseguenza si ripercuote sulle prestazioni.

Per questo motivo, è importante per le decisioni corrette durante la fase di progettazione dell'applicazione. Tuttavia anche se è necessario affrontare un problema di prestazioni utilizzando un'applicazione pronte all'uso in cui sembrano Impossibile modifiche all'applicazione client, i fattori fondamentali che influenzano le prestazioni non viene modificata, non vale a dire che il client svolge un ruolo dominante e molti problemi di prestazioni può essere risolto senza apportare modifiche di client.

Se dispone di un'applicazione ben progettata, SQL Server sarà in grado di supportare migliaia di utenti concorrenti. Mentre con un'applicazione mal progettata, anche la piattaforma server più potete mostrerà scarse prestazioni anche con un numero ridotto di utenti.

Di seguito vengono forniti alcuni suggerimenti per la progettazione di applicazioni client che consentiranno di ottenere buone prestazioni di SQL Server:
  • Utilizzare set di risultati di piccole dimensioni. Recuperare inutilmente grandi insiemi di risultati contenenti ad esempio migliaia di righe, che dovranno essere sfogliati sul client aumenta naturalmente il carico di I/O di rete e il carico della CPU, rende l'applicazione meno efficiente nel servire gli utenti remoti e ne limita la scalabilità. È preferibile per progettare l'applicazione per richiedere all'utente input sufficiente, in modo che le query inviate cui generare il set di risultati con prestazioni modeste.

    Tra le tecniche di progettazione che facilitano questo: limitare l'impiego di caratteri jolly per la creazione di query, rendere obbligatorio l'impiego di determinati campi di input e vietare query improvvisate.
  • Utilizzare correttamente dbcancel() nelle applicazioni DB-Library. Tutte le applicazioni devono consentire l'annullamento di una query in corso. Nessuna applicazione dovrebbe costringere l'utente a riavviare il computer client per annullare la query. Non seguendo questo principio si potrebbero infatti causare problemi di prestazioni che non sarà possibile risolvere. Quando si utilizza dbcancel() è importante prestare attenzione al livello della transazione. Per ulteriori informazioni, vedere il seguente articolo della Microsoft Knowledge Base riportato di seguito:
    117143: INF: quando e come utilizzare dbcancel() o sqlcancel()
    Le problematiche di stesse applicabili alle applicazioni ODBC, se la chiamata sqlcancel() ODBC viene utilizzata.
  • Elaborare sempre tutti i risultati fino al completamento. Non progettare mai un'applicazione o utilizzare mai un'applicazione pronta per l'uso che blocchi l'elaborazione delle righe di risultato senza che venga prima annullata la query. In questo modo verrà in genere causare prestazioni lente e blocco.
  • Implementare sempre un timeout per le query. Non consentire la query da eseguire per un periodo di tempo indefinito. A tal fine eseguire chiamate ODBC o DB-Library appropriate per impostare un timeout per le query. In DB-Library questo viene ottenuto tramite la chiamata dbsettime(), mentre in ODBC tramite SQLSetStmtOption().
  • Non utilizzare uno strumento di sviluppo di applicazioni che non consenta un controllo esplicito delle istruzioni SQL inviate al server. Non utilizzare uno strumento che genera in maniera trasparente istruzioni SQL basate su oggetti di livello superiore a meno che tale strumento non disponga anche di funzioni essenziali che consentano ad esempio l'annullamento delle query, l'impostazione del timeout delle query e il controllo completo delle transazioni. Spesso non è possibile gestire buone prestazioni o per risolvere un problema di prestazioni se l'applicazione da solo genera "SQL trasparente", perché questo non consente il controllo esplicito delle transazioni e il blocco problemi che sono fondamentali per l'immagine di prestazioni.
  • Non mescolare supporto decisionale e online transaction processing (OLTP) query.
  • Non progettare un'applicazione o utilizzare un'applicazione chiave che costringa l'utente a riavviare il computer client per annullare una query. Ciò potrebbe infatti causare una serie di problemi di prestazioni difficilmente risolvibili a causa di possibili connessioni orfane. Per ulteriori informazioni, vedere il seguente articolo della Microsoft Knowledge Base riportato di seguito:
    137983: risoluzione dei problemi connessioni orfane in SQL Server

Tecniche di analisi delle prestazioni

Spesso si può essere tentati di risolvere un problema di prestazioni semplicemente mettendo a punto le prestazioni a livello di sistema. ottimizzando ad esempio la quantità di memoria, il tipo di file system, il numero e il tipo di processori e così via. L'esperienza dei tecnici addetti al supporto di Microsoft SQL Server mostra che la maggior parte dei problemi di prestazioni non può essere risolta in questo modo,. bensì richiede un'attenta analisi dell'applicazione, delle query inviate al database e del tipo di interazione esistente tra query e schema di database.

Innanzitutto è importante isolare la query o le query più lente. Spesso può sembrare che un'intera applicazione sia lenta, mentre in effetti il problema riguarda solo alcune query SQL. Solitamente non è possibile risolvere un problema di prestazioni senza suddividere il problema fino a isolare le query più lente. Se si dispone di uno strumento di sviluppo che genera codice SQL in maniera trasparente, utilizzare qualsiasi modalità di diagnostica o di debug disponibile in questo strumento per catturare il codice SQL generato. In molti casi sono disponibili funzioni di analisi, che però potrebbero non essere apertamente documentate. Contattare il supporto tecnico dell'applicazione per determinare se esiste una funzione di analisi per il monitoraggio delle istruzioni SQL generate dall'applicazione.

Per gli strumenti di sviluppo delle applicazioni che utilizzano SQL incorporato, ciò è molto più facile, dato che l'SQL è visibile.

Se lo strumento di sviluppo o l'applicazione non fornisce una funzione di analisi, esistono comunque numerose alternative:
  • Utilizzare il flag di traccia di 4032 in base alle istruzioni in SQL Server 4.2 x "Troubleshooting Guide" e SQL Server 6.0 "Transact-SQL Reference". Questo consentirà di catturare nel log degli errori SQL le istruzioni SQL inviate al server.
  • Monitorare le query tramite un'applicazione di analisi della rete, quale ad esempio Microsoft Network Monitor, contenuta in Systems Management Server.
  • Per le applicazioni ODBC utilizzare il programma Amministratore ODBC per selezionare la funzione di analisi delle chiamate ODBC. Per ulteriori informazioni in proposito, consultare la documentazione ODBC.
  • Utilizzare un'utilità del lato client di terze parti in grado di intercettare le istruzioni SQL a livello di DB-Library o di ODBC,. quale ad esempio SQL Inspector di Blue Lagoon Software.
  • Utilizzare lo strumento di analisi SQLEye fornito come esempio nel CD di Microsoft TechNet. Nota: SQLEye non è supportata dal supporto tecnico Microsoft.
Una volta isolata la query lenta, attenersi alla seguente procedura:
  • Eseguire la query sospetta isolata utilizzando uno strumento di query, quale ad esempio ISQL, e verificare che la sua esecuzione sia effettivamente lenta. Spesso è consigliabile eseguire la query sul computer server utilizzando ISQL pipe locali e reindirizzando poi i risultati a un file. Questo aiuta a eliminare la presenza di fattori di complicazione, quali I/O di rete e di schermo e la memorizzazione dei risultati dell'applicazione.
  • Utilizzare SET STATISTICS IO ON per esaminare gli I/O utilizzati dalla query. e osservare il numero di I/O di pagina logici. Lo scopo dell'utilità di ottimizzazione è quello di minimizzare il numero di I/O. Segnare il numero di I/O logici. al fine di disporre di un termine di confronto per misurare il miglioramento delle prestazioni. Spesso è più utile concentrare la propria attenzione esclusivamente sull'output di STATISTICS IO e provare a svolgere dei tentativi con diversi tipi di indici e di query anziché utilizzare SET SHOWPLAN ON. L'interpretazione e l'applicazione efficace dell'output di SHOWPLAN può infatti richiedere un certo studio e del tempo che potrebbe essere speso in maniera più redditizia svolgendo dei test empirici. Se il problema di prestazioni non viene risolto seguendo queste semplici raccomandazioni, sarà possibile utilizzare SHOWPLAN per investigare in maniera più approfondita il comportamento dell'utilità di ottimizzazione.
  • Se la query coinvolge una vista o una stored procedure, estrarre la query dalla vista o dalla stored procedure ed eseguirla separatamente. In questo modo il piano di accesso da modificare come è possibile provare con indici diversi. Aiuta anche a localizzare il problema alla query stessa contrariamente a quanto fa l'utilità di ottimizzazione che gestisce invece le viste e le stored procedure. Se il problema non risiede nella query ma si verifica solo quando la query viene eseguita come parte di una vista o di una stored procedure, eseguire la query da sola aiuterà comunque a determinare la sede del problema.
  • Tenere in considerazione i possibili trigger presenti nelle tabelle coinvolte nella query in grado di generare I/O in maniera trasparente durante l'esecuzione del trigger. Si consiglia di rimuovere qualsiasi trigger coinvolto in una query lenta al. fine di determinare se il problema risiede nella query stessa o nel trigger o nella vista e quindi di indirizzare meglio i propri sforzi.
  • Esaminare gli indici delle tabelle utilizzate dalla query lenta. Utilizzare le tecniche elencate in precedenza per determinare se sono indicizzate correttamente, e se necessario, per modificare gli indici. Come primo tentativo, provare a indicizzare ciascuna colonna nella proposizione WHERE. Spesso i problemi di prestazioni sono causati semplicemente dal fatto che nella proposizione WHERE una colonna non è stata indicizzata oppure dal fatto che tale colonna non dispone di un indice utile.
  • Utilizzando le query riportate in precedenza, esaminare l'univocità dei dati e la distribuzione dei dati per ciascuna colonna menzionata nella proposizione WHERE specialmente per ciascuna colonna indicizzata. In molti casi una semplice ispezione della query, della tabella, degli indici e dei dati consentirà di identificare rapidamente la causa del problema. Ad esempio, i problemi di prestazioni sono spesso causati da un indice in una chiave con solo tre o quattro valori univoci o dall'esecuzione di un JOIN in una colonna di questo tipo o ancora da un numero eccessivo di righe ritornate al client.
  • In base a questo studio apportare qualsiasi modifica sia richiesta all'applicazione, alla query o agli indici. Eseguire nuovamente la query dopo aver apportato la modifica e osservare qualsiasi cambiamento nel numero di I/O.
  • Se non si rileva alcun miglioramento, eseguire l'applicazione principale per vedere se le prestazioni generali sono comunque migliorate.
Verificare il comportamento del programma legato agli I/O o alla CPU. Spesso è utile determinare se una query è basata sulla CPU o sugli I/O. Ciò consente di valutare con attenzione il miglioramento sul collo di bottiglia true. Ad esempio, se una query è basata sulla CPU, aggiungendo più memoria a SQL Server non si noterà molto probabilmente alcun miglioramento nelle prestazioni, in quanto una quantità superiore di memoria consente solo di migliorare il rapporto di accessi alla cache, che in questo caso è già elevato.

Come esaminare il comportamento di query basate sugli I/O o sulla CPU:
  • Utilizzare Windows NT Performance Monitor per osservare l'attività di I/O e l'attività della CPU. Osservare tutte le istanze del contatore "% Tempo disco" dell'oggetto LogicalDisk. e del contatore "% Tempo totale processore" dell'oggetto System. Per ottenere informazioni valide sulle prestazioni del disco è necessario aver precedentemente abilitato l'impostazione di Windows NT DISKPERF scegliendo "diskperf -S" da un prompt dei comandi e quindi aver riavviato il sistema. Per ulteriori informazioni in proposito, consultare la documentazione di Windows NT.
  • Se durante l'esecuzione della query, il grafico della CPU presenta un andamento molto elevato, ad esempio superiore al 70%, e il valore "% Tempo disco" è particolarmente ridotto, significa che la query è basata sulla CPU.
  • Se durante l'esecuzione della query, il grafico della CPU presenta un andamento particolarmente ridotto, ad esempio inferiore al 50%, e il valore "% Tempo disco" è particolarmente ridotto, significa che la query è basata sugli I/O.
  • Confrontare il grafico della CPU con le informazioni di STATISTICS IO.

Conclusione

SQL Server, in modo particolare SQL Server versione 6.0, è in grado di garantire ottime prestazioni anche con database di grandi dimensioni. Questo avviene soprattutto con SQL Server 6.0. Per sfruttare pienamente questo potenziale di prestazioni è necessario tuttavia progettazione in maniera efficiente database, applicazioni, query e indici. Questi ambiti sono i candidati migliori per ottenere significativi miglioramenti di prestazioni. Provare a rendere ciascuna query il più efficiente possibile, in modo che anche quando l'applicazione venga utilizzata da più utenti, sia in grado di supportare il maggior carico collettivo. Studiare il comportamento dell'applicazione client, le query inviate all'applicazione e provare a fare delle prove con gli indici seguendo le indicazioni riportate in questo documento. Un approccio metodico all'analisi dei problemi di prestazioni consentirà di ottenere miglioramenti significativi pur con investimenti di tempo relativamente contenuti.

Proprietà

Identificativo articolo: 110352 - Ultima modifica: martedì 22 febbraio 2005 - Revisione: 3.1
Le informazioni in questo articolo si applicano a:
  • Microsoft SQL Server 4.21a Standard Edition
  • Microsoft SQL Server 6.0 Standard Edition
  • Microsoft SQL Server 6.5 Standard Edition
Chiavi: 
kbmt kbinfo kbother KB110352 KbMtit
Traduzione automatica articoli
Il presente articolo è stato tradotto tramite il software di traduzione automatica di Microsoft e non da una persona. Microsoft offre sia articoli tradotti da persone fisiche sia articoli tradotti automaticamente da un software, in modo da rendere disponibili tutti gli articoli presenti nella nostra Knowledge Base nella lingua madre dell?utente. Tuttavia, un articolo tradotto in modo automatico non è sempre perfetto. Potrebbe contenere errori di sintassi, di grammatica o di utilizzo dei vocaboli, più o meno allo stesso modo di come una persona straniera potrebbe commettere degli errori parlando una lingua che non è la sua. Microsoft non è responsabile di alcuna imprecisione, errore o danno cagionato da qualsiasi traduzione non corretta dei contenuti o dell?utilizzo degli stessi fatto dai propri clienti. Microsoft, inoltre, aggiorna frequentemente il software di traduzione automatica.
Clicca qui per visualizzare la versione originale in inglese dell?articolo: 110352
LE INFORMAZIONI CONTENUTE NELLA MICROSOFT KNOWLEDGE BASE SONO FORNITE SENZA GARANZIA DI ALCUN TIPO, IMPLICITA OD ESPLICITA, COMPRESA QUELLA RIGUARDO ALLA COMMERCIALIZZAZIONE E/O COMPATIBILITA' IN IMPIEGHI PARTICOLARI. L'UTENTE SI ASSUME L'INTERA RESPONSABILITA' PER L'UTILIZZO DI QUESTE INFORMAZIONI. IN NESSUN CASO MICROSOFT CORPORATION E I SUOI FORNITORI SI RENDONO RESPONSABILI PER DANNI DIRETTI, INDIRETTI O ACCIDENTALI CHE POSSANO PROVOCARE PERDITA DI DENARO O DI DATI, ANCHE SE MICROSOFT O I SUOI FORNITORI FOSSERO STATI AVVISATI. IL DOCUMENTO PUO' ESSERE COPIATO E DISTRIBUITO ALLE SEGUENTI CONDIZIONI: 1) IL TESTO DEVE ESSERE COPIATO INTEGRALMENTE E TUTTE LE PAGINE DEVONO ESSERE INCLUSE. 2) I PROGRAMMI SE PRESENTI, DEVONO ESSERE COPIATI SENZA MODIFICHE, 3) IL DOCUMENTO DEVE ESSERE DISTRIBUITO INTERAMENTE IN OGNI SUA PARTE. 4) IL DOCUMENTO NON PUO' ESSERE DISTRIBUITO A SCOPO DI LUCRO.
Dichiarazione di non responsabilità per articoli della Microsoft Knowledge Base su prodotti non più supportati
Questo articolo è stato scritto sui prodotti per cui Microsoft non offre più supporto. L?articolo, quindi, viene offerto ?così come è? e non verrà più aggiornato.

Invia suggerimenti

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com