Risoluzione dei problemi delle prestazioni delle query ad Hoc in SQL Server

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

In questa pagina

Sommario

In questo articolo viene descritto come risolvere il rallentamento di molte query simultanee ad hoc in Microsoft SQL Server. Se non si Ŕ stabilito l'origine precisa del problema, consultare l'articolo della Microsoft Knowledge Base prima di continuare:
224587Risoluzione dei problemi delle prestazioni dell'applicazione con SQL Server

Si presume che Ŕ stato utilizzato 224587 KB per restringere l'ambito del problema e aver acquisito un registro di Windows NT Performance Monitor che SQL Profiler traccia che illustrano in dettaglio le colonne dei contatori, eventi e dati specifiche.

Caratteristiche dei problemi di prestazioni

Il problema di prestazioni presenta le seguenti caratteristiche:
  • Le query ad hoc breve che in genere hanno una durata molto breve causare lenta prestazioni complessive del sistema quando un numero elevato di utenti simultanei esecuzione le query.
  • Molto alta o 100 utilizzo della CPU percentuale.
  • Non associato blocco durante i periodi di calo delle prestazioni.

    Rapidamente possibile cercare blocco controllando la colonna BLK l'output di stored procedure sp_who . Se la colonna BLK non Ŕ zero per un numero di sistema PID (SPID), sono Ŕ bloccato.
  • In alcuni casi, sovraccarico di memoria del server e potrebbe essere visualizzato gli errori che sono simili alle seguenti errori:
    Errore: 701, gravitÓ: 17, stato: 1
    Memoria di sistema insufficienti per eseguire la query Ŕ.
    - oppure -
    Msg 8645, livello 17, stato 1, 1 e procedure
    Timeout durante l'attesa delle risorse di memoria eseguire la query. Rieseguire la query.

Miglioramenti di compilazioni di query

Miglioramenti nell'architettura di sistema a partire da SQL Server 7.0, in particolare il query optimizer, Ŕ possibile notare una differenza nell'utilizzo risorse di sistema da applicazioni rispetto alle versioni precedenti di SQL Server. In particolare, SQL Server 7.0 potrebbe mostrare un aumento nell'utilizzo di CPU o memoria, ma in versioni precedenti di SQL Server sono in genere disco I/O associato. Queste modifiche possono essere ricondotti a due fattori:
  • Hash e merge join
  • Tempi di compilazione di query
Le versioni precedenti di SQL Server Ŕ completamente recuperavano iterazioni del ciclo nidificati per eseguire join. Join di loop nidificati utilizzare intrinsecamente I/O disco. A partire da SQL Server 7.0, sono stati introdotti hash e merge join. Hash e merge join non pi¨ in memoria l'elaborazione di join ciclo nidificato. Il risultato logico Ŕ di CPU e utilizzo della memoria Ŕ superiore quando si utilizzano queste tecniche di join. Per ulteriori informazioni sui join hash e l'unione, vedere gli argomenti "Understanding hash join" e "Informazioni sui merge join" nella documentazione in linea di SQL Server 7.0.

Tempi di compilazione di query sono interessati poichÚ query optimizer dispone di ulteriori informazioni disponibili pi¨ nelle versioni precedenti di SQL Server, inclusi le statistiche di colonna, algoritmi di ricerca migliorate e nuove tecniche di join hash e merge e le opzioni. Queste informazioni consente di selezionare il metodo pi¨ efficace per recuperare i dati della query query optimizer. Tuttavia, l'analisi e la considerazione di queste nuove tecniche e informazioni richiede tempi di elaborazione. Questo maggiore utilizzo della CPU potrebbe causare tempi di compilazione query pi¨ nelle versioni precedenti di SQL Server.

Per la maggior parte delle query, questo aumento in fase di compilazione ha uno scarto di una riduzione del tempo di esecuzione. L'effetto complessivo Ŕ la query viene eseguita pi¨ velocemente rispetto in versioni precedenti di SQL Server. Tuttavia, un'unica eccezione, si verifica con query di tipo OLTP molto piccolo, semplice, con tempi di esecuzione molto bassi. Per queste query, il processo di generazione di un piano di query potrebbe essere una spesa maggiore o uguale all'esecuzione della query. Di conseguenza, pu˛ essere eseguita la query leggermente pi¨ lenta nelle versioni precedenti di SQL Server. PoichÚ la differenza Ŕ in genere espresso in millisecondi, questi effetti non sono notati per una particolare query se viene eseguita singolarmente. Tuttavia, si noterÓ che sistema generale dell'utilizzo della CPU sia superiore a nelle versioni precedenti di SQL Server se il numero elevato di query ad hoc viene eseguito contemporaneamente da un numero elevato di utenti.

Sviluppare la query con parametri

SQL Server 7.0 utilizza diverse tecniche di nuovi, ad esempio la memorizzazione nella cache le query ad hoc e parametrizzazione automatica. Tuttavia, le query SQL Server 7.0 parametrizza automaticamente sono limitati. Utilizzare i metodi riportati di seguito per assicurarsi che i piani di query sono parametri e possono essere riutilizzati in modo pi¨ efficace:
  • indicatori di parametro OLE DB e ODBC API consentono di parametri per essere specificato con un punto interrogativo quando gli utenti inviano query. Questo pu˛ essere molto utile in qualsiasi applicazione, soprattutto per applicazioni di livello intermedio che dispongono di moduli di generazione di query in cui l'utilizzo di stored procedure non Ŕ disponibile. Il piano della query generato per query che utilizzano gli indicatori di parametro pu˛ essere riutilizzato da qualsiasi client che eseguono la stessa query, anche se i valori dei diversi parametri viene specificati. Per ulteriori informazioni, vedere l'argomento "Indicatori di parametro" nella documentazione di SQL Server 7.0 in linea.
  • stored procedure sp_executesql La stored procedure sp_executesql stored procedure viene chiamata dal provider OLE DB o driver ODBC quando gli indicatori di parametro sono utilizzati in un'applicazione. Tuttavia, pu˛ essere chiamato anche direttamente dall'applicazione o in un'altra stored procedure per in modo esplicito parametrizzare le query ad hoc. Questo pu˛ essere molto utile in applicazioni o file batch in cui l'istruzione EXECUTE viene utilizzato per eseguire istruzioni SQL dinamiche. A differenza di sp_executesql , l'istruzione EXECUTE non consente la parametrizzazione. Questo limita la possibilitÓ di riutilizzo del piano di query. Per ulteriori informazioni, vedere "sp_executesql (T-SQL)" e "Using sp_executesql" argomenti nella documentazione in linea di SQL Server 7.0.
  • stored procedure Stored procedure avere numerosi vantaggi, inclusa la possibilitÓ di parametrizzare le query e riutilizzare i piani di esecuzione. Per ulteriori informazioni, vedere gli argomenti "Stored procedure" e "Programming Stored Procedures" nella documentazione in linea di SQL Server 7.0.

Visualizzare i dati prestazioni

Utilizzare il Registro di Performance Monitor per determinare quali risorse di sistema causano il collo di bottiglia. Il Registro di Performance Monitor pu˛ fornire un quadro generale del sistema e consentono di focalizzare l'attenzione quando si visualizzano i dati di SQL Profiler. Esaminare i dati prestazioni dal momento che quando le prestazioni Ŕ stata valida tramite l'ora di prestazioni ridotto. Determinare il contatore che Ŕ stato influenzato prima e quindi determinare quale dei seguenti problemi Ŕ pi¨ importanti alla propria situazione:
  • Oggetto: processo
    Contatore: processore
    Istanza: SQL Server
  • Oggetto: processore
    Contatore: % tempo processore
    Istanza: Controlla ciascuna istanza del processore
  • Oggetto: SQL Server: Buffer Manager
    Contatore: Buffer liberi
  • Oggetto: SQL Server: Buffer Manager
    Contatore: Numero di pagine di furto
  • Oggetto: SQL Server: Memory Manager
    Contatore: Memoria concede in sospeso
  • Oggetto: Statistiche SQL: SQL Server
    Contatore: SQL Compilations/sec
Se l'utilizzo CPU, SQL Compilations/sec e buffer liberi contatori sono elevato, concessioni di memoria in sospeso e furto numero di pagine contatori sono minime, ci˛ indica che la CPU Ŕ il collo di bottiglia. Concentrarsi su come applicare parametri e riutilizzo dei piani query per evitare il costo di generazione del piano di query in modo efficiente e vedere la sezione "Raggruppa la traccia SQL Profiler dalla classe di evento" di questo articolo. Se i contatori di compilazioni SQL/sec e di buffer liberi sono minime e i contatori del numero di pagine furto e concessioni di memoria in sospeso sono alti, Ŕ SQL Server con memoria limitata. Concentrarsi sulla ricerca di query in cui gli hash join vengono utilizzati e pu˛ essere modificato in join in ciclo e vedere "Gruppo SQL Profiler traccia per durata" sezione di questo articolo. Per ulteriori informazioni su questi contatori, Ŕ possibile utilizzare il nome del contatore per cercare la documentazione in linea di SQL Server 7.0.

Visualizzare i dati di SQL Profiler

Quando si sono risoluzione di problemi di prestazioni, Ŕ estremamente utile per visualizzare i dati di SQL Profiler. Non Ŕ necessario esaminare tutti i dati che Ŕ stato acquisito, si essere selettiva. SQL Profiler consente di visualizzare in modo efficace i dati di acquisiti. Nella scheda ProprietÓ (scegliere ProprietÓ dal menu file ), SQL Profiler consente di limitare i dati che viene visualizzati per rimuovere colonne di dati o gli eventi, il raggruppamento o ordinamento di colonne di dati e applicazione di filtri. ╚ possibile cercare la traccia intera o solo una colonna specifica per valori specifici (dal menu Modifica , scegliere Trova ). ╚ inoltre possibile salvare i dati di SQL Profiler in una tabella SQL Server (scegliere Salva con nome dal menu file , quindi Tabella di traccia ), e quindi eseguire query SQL su di essa.

Nota Assicurarsi di filtrare solo un file di traccia salvato. Se questa procedura su una traccia attiva, si rischia di perdere i dati che Ŕ stati acquisiti dall'avvio della traccia. Salvare una traccia attiva in un file o la prima tabella (scegliere Salva con nome dal menu file ), quindi riaprirlo (scegliere Apri dal menu file ) prima di continuare. Quando si lavora con un file di traccia salvato, il filtro non permanente rimuove i dati; i dati solo sono nascosto, non Ŕ stato eliminato. Aggiungere e rimuovere eventi e colonne dati consentono di focalizzare le ricerche.

╚ anche necessario concentrarsi sulle aree in cui si riceverÓ il benefit la maggior parte dei. I seguenti fattori consentono di aumentare le prestazioni dell'applicazione ma non necessariamente lo stesso livello. Prima di implementare le modifiche, Ŕ necessario determinare come efficace le modifiche potrebbero essere seconda i seguenti fattori:
  • Frequenza con cui la query viene eseguita
  • La quantitÓ miglioramento che Ŕ possibile migliorare la query
Ad esempio, riducendo il tempo di esecuzione di una singola query da 1,5 secondi a 1,2 secondi potrebbe risultare utile se la query non viene eseguita spesso nel corso della giornata. Tuttavia, se la query viene eseguita molto spesso da un numero elevato di utenti simultanei, il miglioramento delle prestazioni pu˛ risultare molto efficacia. Al contrario, miglioramento di una singola query da 6 minuti a 3 secondi potrebbe non restituire un notevole miglioramento delle prestazioni generali Se viene utilizzato di rado. ╚ possibile utilizzare il raggruppamento e filtro tecniche in SQL Profiler e la conoscenza dell'applicazione per valutare gli effetti di una determinata query o una routine prima di implementare le modifiche. Concentrarsi innanzitutto sulle modifiche pi¨ efficace e procedere con iterazioni altre query e routine fino a raggiungere un livello in cui sono sufficientemente migliorato le prestazioni.

Dopo aver salvato una traccia SQL Profiler a un file o una tabella, riaprire la traccia in SQL Profiler ed esaminare il contenuto. Per raggruppare la traccia di SQL Profiler, attenersi alla seguente procedura:
  • Raggruppare la traccia di SQL Profiler per durata:
    1. Nel menu file , fare clic su ProprietÓ .
    2. Fare clic sulla scheda Colonne di dati e quindi fare clic su su per spostare la durata in gruppi . Fare clic su gi¨ per rimuovere tutte le altre colonne.
    3. Fare clic sulla scheda eventi e quindi rimuovere tutti gli eventi tranne SQL:StmtCompleted TSQL e TSQL RPC: Completed . Consente di concentrarsi su solo le query che vengono eseguite.
    4. Fare clic su OK .
    Raggruppamento per durata consente di visualizzare facilmente il codice SQL le istruzioni, batch e procedure che eseguono la minima. L'analisi quando si verifica il problema e creare una base di buone prestazioni. ╚ possibile filtrare per ora di inizio per suddividere la traccia in sezioni quando le prestazioni sono sezioni separate e buona quando le prestazioni sono scarse. Verificare quali query richiedevano tempi di esecuzione pi¨ lunghi nel periodo di prestazioni soddisfacenti. ╚ molto probabile che siano proprio queste query la causa del problema. Quando diminuisce le prestazioni complessive del sistema, buona anche query possibile visualizzare le durate lunghe perchÚ in attesa per le risorse di sistema.

    Rivedere i piani di esecuzione per le query che la maggior parte spesso dispongono di lunga durata. Se si verificare che Ŕ viene utilizzato un hash join, Ŕ consigliabile utilizzare l'hint di query di JOIN LOOP per forzare un join di loop nidificati per la query. Se il tempo di esecuzione per la query utilizza un join ciclo Ŕ minore, uguale o leggermente maggiore il tempo di esecuzione con l'hash join, Ŕ possibile che un join di loop possibile un'opzione migliore se il computer Ŕ elevata di memoria e CPU. Riducendo la sollecitazione del collo di bottiglia risorse (CPU e memoria), Ŕ possibile migliorare le prestazioni complessive del sistema. Per ulteriori informazioni per il JOIN di LOOP query suggerimento, vedere l'argomento di "SELECT (T-SQL)" nella documentazione in linea di SQL Server 7.0.
  • La traccia di SQL Profiler raggruppamento della classe di evento:
    1. Nel menu file , fare clic su ProprietÓ .
    2. Fare clic sulla scheda Colonne di dati e quindi fare clic su su per spostare Event Class e Text con Classe di evento nella parte superiore sotto l'intestazione gruppi . Fare clic su gi¨ per rimuovere tutte le altre colonne sotto l'intestazione gruppi .
    3. Fare clic sulla scheda eventi e assicurarsi che siano inclusi tutti gli eventi.
    4. Fare clic su OK .

Tipi di eventi

Per visualizzare i tipi di eventi si verificano nel computer che esegue SQL Server e la frequenza con cui gli eventi si verificano, Raggruppa per la colonna Event Class . Cercare in questa colonna i seguenti eventi:
  • varie: preparazione di SQL ed Exec preparati SQL; Cursor: Cursorprepare Un evento di Prepare SQL indica che un'istruzione SQL Ŕ stata configurata per utilizzare con un set di risultati predefinito (cursore sul lato client) utilizzando SQLPrepare/SQLExecute (per ODBC) o ICommandText::Prepare/ICommandText::Execute (per OLE DB) con le opzioni del cursore predefinito: Avanti, sola lettura, dimensioni del set di righe = 1. Un evento Cursorprepare indica che un cursore sul lato server Ŕ stato preparato in un SQL impostata di istruzione utilizzando SQLPrepare/SQLExecute (per ODBC) o ICommandText::Prepare/ICommandText::Execute (per OLE DB) con quello delle precedenti opzioni cursore su un valore di non predefinito. Un evento di Exec Prepared SQL indica che uno dei tipi precedenti di istruzioni preparate esistente Ŕ stata eseguita. Se viene visualizzato spesso occorrenze di questi eventi, l'applicazione utilizza il modello di preparazione/esecuzione durante l'apertura di risultato set. In tal caso, Ŕ necessario determinare se si utilizza il modello di preparazione/esecuzione correttamente.

    In teoria, un'applicazione prepara un'istruzione SQL una sola volta e viene eseguita pi¨ volte in modo che query optimizer non debba compilare un piano di nuovo ogni volta che viene eseguita l'istruzione. Ogni volta che si esegue un'istruzione preparata, Ŕ possibile salvare il costo della compilazione della query. Se si intende eseguire una query una volta, si consiglia di non preparare. La preparazione e quindi l'esecuzione di un'istruzione SQL richiede tre comunicazioni di rete: uno per preparare l'istruzione, uno per eseguire l'istruzione e uno per l'annullamento preparazione dell'istruzione. Preparazione di cursori sul lato server richiede almeno cinque round trip: uno per preparare il cursore, per eseguire o aprire il file, uno o pi¨ per recuperare da esso, uno per chiuderlo e l'altro annullamento preparazione. L'esecuzione della query richiede solo un collegamento.

    Per visualizzare l'efficacia con l'applicazione utilizza il modello di preparazione/esecuzione, confrontare il numero di volte in cui questi due eventi (Preparazione ed esecuzione) si verificano. Il numero di eventi Exec Prepared SQL deve essere molto superiore il totale di Prepare SQL e gli eventi CursorPrepare (almeno tre a cinque volte pi¨ grande Ŕ una buona stima). Ci˛ indica che le istruzioni preparate sono da riutilizzare con una frequenza sufficiente per superare il maggiore sovraccarico per crearli. Se il numero di eventi Prepare SQL e CursorPrepare Ŕ approssimativamente al numero di eventi Exec Prepared SQL , potrebbe significare che l'applicazione non utilizzi in modo efficace il modello di preparazione/esecuzione. Provare a preparare un'istruzione una sola volta e riutilizzarlo quanto possibile. ╚ inoltre possibile modificare l'applicazione per preparare le istruzioni in una sola volta e riutilizzare le istruzioni.

    ╚ necessario scrivere l'applicazione in modo specifico per utilizzare in modo efficiente il modello di preparazione/esecuzione. La durata di un handle per un'istruzione preparata Ŕ controllata da quanto tempo Ŕ mantenere il HSTMT aperto in oggetto ICommandText in OLE DB o ODBC. Una pratica comune consiste nell'ottenere un oggetto HSTMT, preparare un'istruzione SQL, eseguire l'istruzione preparata e liberare HSTMT, con una conseguente perdita l'handle al piano preparato. Se si esegue questa operazione, non viene visualizzato alcun vantaggio dal modello di preparazione/esecuzione. Infatti, potrebbe essere visualizzato un calo delle prestazioni causa dell'overhead aggiuntivo di comunicazioni di rete. L'applicazione deve disporre un metodo per memorizzare nella cache l'HSTMT o l'oggetto con l'handle di istruzione preparata e per accedervi per il riutilizzo. Il driver o il provider non automaticamente, l'applicazione Ŕ responsabile l'implementazione, gestione e utilizzando queste informazioni. Se l'applicazione pu˛ farlo, Ŕ consigliabile utilizzare gli indicatori di parametro anzichÚ il metodo di preparazione/esecuzione.
  • utilizzando gli indicatori di parametro Le applicazioni possono utilizzare gli indicatori di parametro per ottimizzare l'uso della stessa istruzione Transact-SQL pi¨ volte con valori di output e input diversi. La prima volta che viene eseguita una query, come una query con parametri Ŕ stato preparato e SQL Server genera e memorizza nella cache un piano con parametri per la query. Per le chiamate successive la stessa query utilizzando i parametri stessi o diversi, non dispone di SQL Server generare un nuovo piano di query, SQL Server Ŕ possibile riutilizzare il piano di query esistente sostituendo i parametri correnti.

    Se l'applicazione utilizza gli indicatori di parametro con chiamate a SQLExecDirect (per ODBC) o ICommandText::Execute (per OLE DB), automaticamente il driver o il provider inserisce l'istruzione SQL e viene eseguito come una chiamata di stored procedure sp_executesql . L'istruzione non Ŕ preparato e l'esecuzione separatamente. Quando SQL Server riceve una chiamata a sp_executesql , Ŕ automaticamente controlla la cache delle procedure per un piano corrispondente e riutilizza il piano o genera un nuovo piano.

    Per determinare se l'applicazione utilizza attualmente gli indicatori di parametro, puoi cercare la colonna di testo nella traccia SQL Profiler per "sp_executesql." Tuttavia, poichÚ sp_executesql pu˛ essere chiamato direttamente, non tutte le istanze indicano l'utilizzo di indicatori di parametro.

    Per ulteriori informazioni sul modello di preparazione/esecuzione, vedere "Esecuzione piano Caching e riutilizzo" nella documentazione in linea di SQL Server 7.0. Per ulteriori informazioni su indicatori di parametro, vedere l'argomento di "Indicatori di parametro" nella documentazione in linea di SQL Server 7.0.
  • SP: Completed Istruzioni SQL dinamiche eseguite con il comando EXECUTE vengono visualizzate come un SP: Completed evento con il testo "SQL dinamico." Espandere il SP: completata evento e quindi cercare tutte le occorrenze che dispongono di "SQL dinamico" come testo. Se sono presenti molti di questi eventi, Ŕ possibile migliorare le prestazioni dell'applicazione, utilizzare sp_executesql anzichÚ l'istruzione EXECUTE. La stored procedure sp_executesql stored procedure consente di riutilizzare i piani di esecuzione se la stessa query viene eseguita utilizzando diversi parametri di SQL Server. Quando si utilizza l'istruzione EXECUTE, il piano non Ŕ con parametri e non viene riutilizzato, a meno che la query viene eseguita nuovamente utilizzando gli stessi parametri.

    Per determinare la query o la routine che utilizzano eventi SQL dinamici con l'istruzione EXECUTE istruzione, annotare l'ID di connessione e ora di inizio di per ogni evento. Separare la traccia (rimuovere Event Class e Text dell'intestazione Groups ). Dopo che si separa l'analisi, viene ordinato in ordine cronologico. ╚ possibile filtrare la traccia dall'ID di connessione (scheda filtri ) e quindi rimuovere tutte le classi di evento ad eccezione di SP: avvio e SP: completata eventi per una maggiore leggibilitÓ. ╚ quindi possibile cercare l'ora di inizio dell'evento (dal menu Modifica , scegliere Trova ). I risultati indicano quando l'evento SQL dinamico avviato. Se si Ŕ verificato l'evento in una stored procedure, l'evento viene visualizzato tra il SP: avvio e SP: completata eventi per tale routine. Se l'evento non Ŕ stato generato in una stored procedure, che Ŕ stato eseguito come una query ad hoc ed Ŕ possibile utilizzare le altre colonne di dati ( Application Name , NT User Name e altri) per determinare in cui Ŕ stato eseguito il comando. Per determinare il testo del comando e il contesto in cui Ŕ stato eseguito, Ŕ inoltre possibile aggiungere classi di evento, ad esempio SQL: BatchCompleted e SQL:RPCCompleted .

    Dopo aver determinato dove viene utilizzata l'istruzione EXECUTE, si consiglia di sostituirlo con una chiamata a sp_executesql . Si consideri ad esempio il seguente scenario in cui il EXECUTE comando viene utilizzato con SQL dinamico. Una routine accetta un nome di tabella, ID e idValue come parametri di input e viene quindi eseguita un'istruzione SELECT dalla tabella basata sul valore ID. Utilizzo di un'istruzione EXECUTE, la procedura Ŕ simile al codice riportato di seguito:
    drop proc dynamicUsingEXECUTE
    		  go create proc dynamicUsingEXECUTE @table sysname, @idName varchar(10),
    		  @idValue varchar(10) as declare @query nvarchar(4000) -- Build query string
    		  with parameter. -- Notice the use of escape quotes. select @query = 'select *
    		  from ' + @table + ' where ' + @idName + ' = ''' + @idValue + '''' exec (@query)
    		  go
    presupponendo che la query non automaticamente Ŕ parametrizzata, se si esegue questa procedura in base alla tabella titles nel database di esempio pubs due volte con valori diversi di @ idValue parametro, SQL Server deve generare un piano di query separata per ogni esecuzione. Ad esempio:
    exec dynamicUsingEXECUTE
    		  'titles', 'title_id', 'MC2222' go exec dynamicUsingEXECUTE 'titles',
    		  'title_id', 'BU7832'
    Nota In questo esempio, la query Ŕ abbastanza semplice che SQL Server possibile parametrizzare automaticamente ed effettivamente riutilizzare il piano di esecuzione. Tuttavia, se questa Ŕ una query complessa non potrebbe parametrizzare automaticamente SQL Server, SQL Server potrebbe non riutilizzare il piano per la seconda esecuzione se il @ idValue parametro Ŕ stato modificato. La seguente query semplice limita la complessitÓ dell'esempio.

    ╚ possibile riscrivere la procedura per utilizzare sp_executesql invece l'istruzione EXECUTE. Il supporto per la sostituzione del parametro rende sp_executesql pi¨ efficienti quanto genera piani di esecuzione che pi¨ probabilmente essere riutilizzato da SQL Server. Ad esempio:
    drop proc dynamicUsingSP_EXECUTESQL go create proc
    		  dynamicUsingSP_EXECUTESQL @table sysname, @idName varchar(10), @idValue
    		  varchar(10) as declare @query nvarchar(4000) -- Build query string with
    		  parameter select @query = 'select * from ' + @table + ' where ' + @idName + ' =
    		  @idValue' -- Now execute with parameter exec sp_executesql @query, N'@idValue
    		  varchar(10)', @idValue go exec dynamicUsingSP_EXECUTESQL 'titles', 'title_id',
    		  'MC2222' go exec dynamicUsingSP_EXECUTESQL 'titles', 'title_id',
    		  'BU7832'
    in questo esempio, la prima volta che viene eseguita l'istruzione sp_executesql , SQL Server genera un con parametri piano per l'istruzione SELECT da titoli con title_id come parametro. Per la seconda esecuzione, SQL Server riutilizza il piano con il nuovo valore del parametro. Per ulteriori informazioni sulla stored procedure sp_executesql , vedere "sp_executesql (T-SQL)" e "Using sp_executesql" argomenti nella documentazione in linea di SQL Server 7.0.
  • SP:RECOMPILES Questo evento indica che una stored procedure Ŕ stata ricompilata durante l'esecuzione. Molti eventi di ricompilazione indica che SQL Server utilizza le risorse per la compilazione query anzichÚ l'esecuzione di query.
Se non viene visualizzato uno di questi eventi, l'applicazione Ŕ in esecuzione solo le query ad hoc in SQL Server. A meno che non SQL Server determina che Ŕ possibile parametrizzare automaticamente determinate query o se gli stessi parametri vengono utilizzati pi¨ volte, ogni query che viene eseguito richiede SQL Server per generare un nuovo piano di esecuzione. SQL Server Performance Monitor dovrebbe visualizzare molti SQL Compilations/sec. Pu˛ trattarsi di intensivo della CPU per molti utenti concorrenti. Per risolvere questo problema, individuare pi¨ eseguite spesso query e provare a creare le stored procedure per queste query, utilizzando gli indicatori di parametro o utilizzo di sp_executesql .

Riferimenti

Per ulteriori informazioni sul monitoraggio e risoluzione dei problemi di prestazioni in SQL Server, fare clic sui numeri degli articoli della Microsoft Knowledge Base riportato di seguito:
224587Risoluzione dei problemi delle prestazioni dell'applicazione con SQL Server
224453INF: Understanding e la risoluzione di SQL Server 7.0 o 2000 problemi di blocco
243586Risoluzione dei problemi di ricompilazione delle stored procedure
243589Come risolvere la query con esecuzione lenta su SQL Server 7.0 o versione successiva
251004INF: Come monitorare i blocchi SQL Server 7.0

ProprietÓ

Identificativo articolo: 243588 - Ultima modifica: giovedý 8 dicembre 2005 - Revisione: 5.4
Le informazioni in questo articolo si applicano a:
  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2000 64-bit Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Standard Edition
Chiavi:á
kbmt kbhowtomaster kbhowto kbinfo KB243588 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: 243588
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.

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