Opzioni per l'impostazione del suggerimento NOLOCK nelle query del set di dati

Un po 'di contesto:
all'inizio abbiamo scritto rapporti semplicemente "diretti", senza alcun suggerimento di blocco nelle query. Con i report più grandi ciò a volte potrebbe causare problemi di blocco. Al primo abbiamo rimediato questo utilizzando il WITH (NOLOCK)suggerimento per le tabelle nella query.

Perché (a) è abbastanza invadente, e (b) è facile dimenticare il suggerimento per uno dei tavoli, si è passati ad una seconda impostazione approccio TRANSACTION ISOLATION LEVELal READ UNCOMMITTED(che va bene) nella parte superiore di interrogazione di ogni set di dati.

Come puoi immaginare, è ancora facile dimenticare il suggerimento per uno dei set di dati. Quindi questo porta alla domanda:

Domanda: quali sono le opzioni per l'invio di NOLOCKsuggerimenti insieme alle query dei rapporti?

PS. Mi rendo conto che questo è in qualche modo un problema XY (con molte altre mie opzioni per X, come l'ottimizzazione della query, non fare report sul database operativo, ecc.), Ma ho comunque cercato di renderlo una domanda valida su se stesso .

Opzioni:
ecco le opzioni sopra menzionate, con opzioni aggiunte sulle quali sono curioso di sapere se funzionerebbero:

1. Imposta un WITH (NOLOCK)suggerimento per ogni tabella. (invadente, molto facile da dimenticare)
2. Impostare il livello di isolamento su READ UNCOMMITTEDper l'intera query. (ancora facile da dimenticare)
3. È possibile specificarlo a livello di report ? Ad esempio, assicurarsi che tutte le query del set di dati per un report vengano eseguite senza blocco.
4. È possibile specificarlo a qualche altro livello SSRS ? Ad esempio, è possibile impostarlo per una determinata cartella di report o utilizzando un'estensione?
5. È possibile specificarlo a livello di origine dati / stringa di connessione ? Ad esempio, tutti i report pertinenti utilizzano una determinata "origine dati senza blocco"?
6. Relativo all'opzione precedente: forse è possibile specificare un suggerimento di blocco predefinito per uno specifico "no-lock-sql-user" (quello utilizzato nella connessione)?
7. ???

Quali opzioni sono praticabili? Ci sono opzioni che mi sono persa?

Risposte rapide:

1. Funziona, come hai notato.
2. Funziona, come hai notato.
3. Questo non sembra funzionare. Non ho visto un'opzione a mano libera e ogni volta che viene posta la domanda, la risposta torna sempre all'impostazione del livello di isolamento nella procedura memorizzata .
4. Non ci credo. SSRS ha un livello di astrazione più elevato rispetto al motore di database, quindi in un certo senso non si preoccupa di quale sia il livello di isolamento - dopotutto, è possibile utilizzare soluzioni non RDBMS nei report.
5. Questo non funziona. Non è possibile impostare il livello di isolamento nella stringa di connessione .
6. Questo potrebbe funzionare. È possibile creare un trigger di accesso .

Esistono alcune opzioni valide se i report sono ottimizzati e continuano a causare problemi:

1. Utilizzare Sempre attivo se si dispone di SQL 2012. È quindi possibile disporre di una replica di sola lettura che i report SSRS potrebbero utilizzare.
2. Usa la replica: istantanea se non hai bisogno in tempo reale e transazionale se ne hai bisogno per essere vicino al tempo reale.
3. Se non si dispone del budget per Always On o della pazienza per gestire la replica, eseguire la replica a basso costo: creare uno schema adatto ai report (ad esempio, denormalizzare le tabelle e metterle in un formato che semplifichi l'esecuzione dei report ) e utilizzare SSIS per alimentare quello schema di report. Funziona meglio se gli utenti finali possono vivere con dati "meno recenti" (ad es. Aggiornamento orario o ogni 5 minuti). Il rovescio della medaglia è che progetterai il modello di dati due volte: una volta per il modello OLTP e una volta per il modello di pseudo-deposito. Il vantaggio è che se ti sposti nella direzione di un data warehouse centralizzato, questo è un esercizio molto utile.

Hai preso in considerazione il controllo delle READ_COMMITTED_SNAPSHOTversioni delle righe per il database?

Kim Tripp ha un buon articolo a riguardo su http://msdn.microsoft.com/en-us/library/ms345124%28v=sql.90%29.aspx

READ_COMMITTED_SNAPSHOTconsente una funzionalità migliore rispetto WITH (NOLOCK)a quella in quanto fornisce coerenza point-in-time assoluta per aggregazioni o query di lunga durata con throughput aumentato a causa della riduzione dei conflitti di blocco.