Seguito della performance estiva Palooza 2013

Il 27 giugno, il PASS Performance Virtual Chapter ha tenuto il Summer Performance Palooza 2013, una specie di 24 ore di PASS in scala ridotta, ma incentrato esclusivamente su argomenti relativi alle prestazioni. Ho tenuto una sessione intitolata "10 cattive abitudini che possono uccidere le prestazioni", trattando i seguenti 10 concetti:

1. SELEZIONA *
2. Indici ciechi
3. Nessun prefisso dello schema
4. Opzioni del cursore predefinite
5. prefisso sp_
6. Consentire il riempimento della cache
7. Tipi di dati ampi
8. Impostazioni predefinite di SQL Server
9. Utilizzo eccessivo delle funzioni
10. "Funziona sulla mia macchina"

Potresti ricordare alcuni di questi argomenti da presentazioni come il mio discorso "Cattive abitudini e buone pratiche" o i nostri webinar settimanali sull'ottimizzazione delle query che ho ospitato con Kevin Kline dall'inizio di giugno fino a questa settimana. (Questi 6 video, tra l'altro, saranno disponibili all'inizio di agosto su YouTube.)

La mia sessione ha avuto 351 partecipanti e ho ricevuto ottimi feedback. Volevo affrontare alcune di queste cose.

Innanzitutto, un problema di configurazione:stavo usando un microfono nuovo di zecca e non avevo idea che ogni sequenza di tasti suonasse come un tuono. Ho risolto il problema con un migliore posizionamento delle mie periferiche, ma voglio scusarmi con tutti coloro che ne sono stati colpiti.

Successivamente, i download; il mazzo e i campioni vengono pubblicati sul sito dell'evento. Sono in fondo alla pagina, ma puoi anche scaricarli qui.

Infine, quello che segue è un elenco di domande che sono state pubblicate durante la sessione e volevo assicurarmi di aver risposto a tutte quelle a cui non è stata data risposta durante la sessione di domande e risposte dal vivo. Mi scuso di averlo inserito in poco meno di un mese , ma c'erano molte domande e non volevo pubblicarle in parti.

R: Dovrai affrontarlo caso per caso, poiché dipenderà davvero da una varietà di fattori (inclusa la complessità del piano). Nota anche che puoi eseguire la ricompilazione a livello di istruzione in modo tale che solo le istruzioni interessate debbano subire il colpo, al contrario dell'intero modulo. Paul White mi ha ricordato che le persone spesso "aggiustano" lo sniffing dei parametri con RECOMPILE , ma troppo spesso ciò significa WITH RECOMPILE in stile 2000 piuttosto che il molto migliore OPTION (RECOMPILE) , che non solo si limita all'istruzione, ma abilita anche l'incorporamento dei parametri, che WITH RECOMPILE non. Quindi, se hai intenzione di usare RECOMPILE per contrastare lo sniffing dei parametri, aggiungilo all'istruzione, non al modulo.

R: Come sopra, questo dipenderà dal costo e dalla complessità dei piani e non c'è modo di dire "Sì, ci sarà sempre un grande successo di prestazioni". Devi anche assicurarti di confrontarlo con l'alternativa.

R: Non sono sicuro di cosa significhi "leggibile nel mondo reale". Se intendi dire che desideri l'output in un formato specifico, di solito è meglio convertire in una stringa sul lato client. C# e la maggior parte delle altre lingue che probabilmente stai utilizzando a livello di presentazione sono più che in grado di formattare l'output di data/ora dal database in qualsiasi formato regionale desideri.

R: La maggior parte dei DMV è valida solo dall'ultimo avvio del servizio e anche altri possono essere lavati più frequentemente (anche su richiesta, sia inavvertitamente che di proposito). La cache del piano è, ovviamente, in costante flusso e i piani AFAIK che escono dalla cache non mantengono il conteggio precedente se tornano indietro. Quindi anche quando vedi un piano nella cache non sono al 100% fiducioso puoi credere al conteggio degli usi che trovi.

Detto questo, quello che probabilmente stai cercando è sys.dm_exec_cached_plans.usecounts e potresti anche trovare sys.dm_exec_procedure_stats.execution_count per aiutare a integrare le informazioni per le procedure in cui le singole istruzioni all'interno delle procedure non si trovano nella cache.

R: Le principali preoccupazioni riguardo a questo sono la possibilità di utilizzare determinate sintassi, come OUTER APPLY o variabili con una funzione con valori di tabella. Non sono a conoscenza di casi in cui l'utilizzo di una compatibilità inferiore abbia un impatto diretto sulle prestazioni, ma un paio di cose generalmente consigliate sono ricostruire gli indici e aggiornare le statistiche (e far sì che il fornitore supporti il ​​livello di compatibilità più recente al più presto). L'ho visto risolvere il degrado imprevisto delle prestazioni in un numero considerevole di casi, ma ho anche sentito alcune opinioni secondo cui non è necessario e forse anche poco saggio.

R: No, almeno in termini di prestazioni, un'eccezione dove SELECT * non importa è quando viene utilizzato all'interno di un EXISTS clausola. Ma perché dovresti usare * qui? Preferisco usare EXISTS (SELECT 1 ... – l'ottimizzatore li tratterà allo stesso modo, ma in un certo senso auto-documenta il codice e assicura che i lettori capiscano che la sottoquery non restituisce alcun dato (anche se manca il grande EXISTS fuori). Alcune persone usano NULL , e non ho idea del motivo per cui ho iniziato a usare 1, ma trovo NULL anche poco intuitivo.

*Nota* dovrai fare attenzione, se provi a usare EXISTS (SELECT * all'interno di un modulo associato a uno schema:

CREATE VIEW dbo.ThisWillNotWork
WITH SCHEMABINDING
AS
  SELECT BusinessEntityID
    FROM Person.Person AS p
	WHERE EXISTS (SELECT * FROM Sales.SalesOrderHeader AS h
	  WHERE h.SalesPersonID = p.BusinessEntityID);

Viene visualizzato questo errore:

Tuttavia cambiandolo in SELECT 1 funziona bene. Quindi forse questo è un altro argomento per evitare SELECT * anche in quello scenario.

R: Probabilmente ce ne sono centinaia in una varietà di lingue. Come le convenzioni di denominazione, gli standard di codifica sono una cosa molto soggettiva. Non importa quale convenzione tu decida che funzioni meglio per te; se ti piace tbl prefissi, impazzisci! Preferisci Pascal a bigEndian, fallo. Vuoi anteporre ai nomi delle colonne il tipo di dati, ad esempio intCustomerID , non ho intenzione di fermarti. La cosa più importante è definire una convenzione e utilizzarla *coerentemente.*

Detto questo, se vuoi le mie opinioni, non mi mancano.

R: Non conosco alcun piano per ritirare XACT_ABORT quindi dovrebbe continuare a funzionare bene. Francamente non lo vedo usato molto spesso ora che abbiamo TRY / CATCH (e THROW a partire da SQL Server 2012).

R: Non l'ho testato, ma in molti casi la sostituzione di una funzione scalare con una funzione inline con valori di tabella può avere un grande impatto sulle prestazioni. Il problema che trovo è che fare questo passaggio può richiedere una notevole quantità di lavoro sul sistema che è stato scritto prima di APPLY esistevano o sono ancora gestiti da persone che non hanno adottato questo approccio migliore.

R: Mi vengono in mente due cose:(1) il ritardo ha a che fare con il tempo di compilazione o (2) il ritardo ha a che fare con la quantità di dati che viene caricata per soddisfare la query e la prima volta deve provenire dal disco e non memoria. Per (1) puoi eseguire la query in SQL Sentry Plan Explorer e la barra di stato ti mostrerà il tempo di compilazione per la prima e le successive invocazioni (anche se un minuto sembra piuttosto eccessivo per questo e improbabile). Se non trovi alcuna differenza, potrebbe essere solo la natura del sistema:memoria insufficiente per supportare la quantità di dati che stai tentando di caricare con questa query in combinazione con altri dati che erano già nel pool di buffer. Se ritieni che nessuno di questi sia il problema, verifica se le due diverse esecuzioni producono effettivamente piani diversi:se ci sono differenze, pubblica i piani su answer.sqlperformance.com e saremo felici di dare un'occhiata . In effetti, l'acquisizione di piani effettivi per entrambe le esecuzioni utilizzando Plan Explorer, in ogni caso, può anche farti conoscere eventuali differenze nell'I/O e può portare a dove SQL Server sta trascorrendo il suo tempo nella prima esecuzione più lenta.

R: No, non credo che l'impostazione Ottimizza per carichi di lavoro ad hoc aiuterà questo scenario, poiché lo sniffing dei parametri implica che le esecuzioni successive dello stesso piano vengano utilizzate per parametri diversi e con comportamenti prestazionali significativamente diversi. Ottimizza per carichi di lavoro ad hoc viene utilizzato per ridurre al minimo l'impatto drastico sulla cache dei piani che può verificarsi quando si dispone di un numero elevato di istruzioni SQL diverse. Quindi, a meno che tu non stia parlando dell'impatto sulla cache del piano di molte diverse istruzioni che stai inviando a sp_executesql – che non sarebbe caratterizzato come sniffing dei parametri – penso di sperimentare con OPTION (RECOMPILE) potrebbe avere un risultato migliore oppure, se conosci i valori dei parametri che *non* producono buoni risultati in una varietà di combinazioni di parametri, usa OPTIMIZE FOR . Questa risposta di Paul White potrebbe fornire informazioni molto migliori.

R: Certo, includi semplicemente OPTION (RECOMPILE) nel testo SQL dinamico:

DBCC FREEPROCCACHE;
 
USE AdventureWorks2012;
GO
SET NOCOUNT ON;
GO
 
EXEC sp_executesql 
  N'SELECT TOP (1) * INTO #x FROM Sales.SalesOrderHeader;';
GO
EXEC sp_executesql 
  N'SELECT TOP (1) * INTO #x FROM Sales.SalesOrderDetail OPTION (RECOMPILE);'
GO
 
SELECT t.[text], p.usecounts
FROM sys.dm_exec_cached_plans AS p
CROSS APPLY sys.dm_exec_sql_text(p.[plan_handle]) AS t
WHERE t.[text] LIKE N'%Sales.' + 'SalesOrder%';

Risultati:1 riga che mostra il Sales.SalesOrderHeader interrogazione.

Ora, se una qualsiasi istruzione nel batch NON include OPTION (RECOMPILE) , il piano potrebbe essere ancora memorizzato nella cache, semplicemente non può essere riutilizzato.

DBCC FREEPROCCACHE(0x06.....);