Come capire il rapporto di lettura / scrittura in SQL Server?
Domanda
Come posso interrogare il rapporto di lettura / scrittura in SQL Server 2005? Ci sono avvertimenti che dovrei essere a conoscenza?
Forse si può trovare in una query DMV, un report standard, un rapporto personalizzato (cioè la Performance Dashboard), o l'esame di una traccia di SQL Profiler. Io non so esattamente.
Perché mi interessa?
sto prendendo tempo per migliorare le prestazioni del livello di dati la mia web app. Si tratta di milioni di dischi e migliaia di utenti.
Uno dei punti che sto esaminando è database di concorrenza. SQL Server utilizza concorrenza pessimistica di default - buono per un'applicazione write-pesante. Se la mia applicazione è lettura pesante, potrei passare a concorrenza ottimistica (livello di isolamento: read committed snapshot
) come Jeff Atwood ha fatto con StackOverflow .
Soluzione
- cerca, scansioni, le ricerche sono tutti si legge
- aggiornamenti sono scrive
Tenete a mente che i contatori vengono resettati ad ogni riavvio del server, è necessario guardare a loro solo dopo un carico rappresentativo è stato eseguito.
Ci sono anche alcuni contatori delle prestazioni che può aiutare a:
- Richieste batch / sec : numero di comando Transact-SQL lotti ricevuti al secondo.
- Write operazioni / sec : numero di transazioni che ha scritto al il database e impegnata ??li>
- operazioni / sec : numero di transazioni iniziate per il database
Da queste tariffe è possibile ottenere una buona stima abbastanza di lettura:. Rapporto di scrittura delle vostre richieste
dopo l'aggiornamento
Accensione l'archivio versione è probabilmente il miglior via per trattare con la concorrenza. Invece di utilizzare l'isolamento dello snapshot in modo esplicito, mi consiglia di accendere lettura istantanea impegnato:
alter database <dbname> set allow_snapshot_isolation on;
alter database <dbname> set read_committed_snapshot on;
legge In questo modo sarà Read Committed (es. quelli di default) per l'utilizzo di snapshot, invece, in modo che letteralmente non richiede alcun cambiamento nella app e può essere rapidamente testato.
Si dovrebbe anche indagare se il vostro letture non sono eseguite sotto la serializzazione legge livello di isolamento, che è ciò che accade quando un TransactionScope viene usato w / o specificare esplicitamente il livello di isolamento.
Una parola di cautela che il negozio versione non è esattamente libero. Vedere versioni delle righe Uso delle Risorse . E si dovrebbe dare una lettura a SQL Server 2005 versioni delle righe based di isolamento delle transazioni .
Altri suggerimenti
Tutte le applicazioni sono pesanti sola lettura.
- Un aggiornamento è una lettura per la clausola WHERE seguita da una scrittura
- Un INSERT deve controllare gli indici e FKS unici, che sono legge e perché le colonne di indice FK
Al la maggior parte Hai 15% scrive. Ho visto un articolo, una volta a discutere, ma non riesco a trovare di nuovo. Più probabilmente l'1%.
So che nelle nostre 6 milioni di nuove righe al giorno DB, abbiamo ancora un minimo del 95% + legge (una stima ovviamente).
Perché avete bisogno di sapere?
Inoltre: Come scoprire di SQL Server del tavolo lettura / scrittura statistiche?
Modifica, in base all'aggiornamento domanda ...
I lascerebbe DB concorrenza fino al momento di cambiarlo. Non abbiamo cambiato qualcosa fuori dalla scatola per i nostri 6 milioni di righe + pesante legge troppo
Per la messa a punto la nostra applicazione web, abbiamo progettato per ridurre i viaggi andata e ritorno (una chiamata = una sola azione, record mutliple per chiamata etc)
Come di trovare un rapporto di contatori num_of_writes
& num_of_reads
in sys.dm_io_virtual_file_stats
?
L'ho fatto utilizzando SQL Server Profiler. Ho appena aperto prima di eseguire l'applicazione e provato che tipo di query vengono eseguite, mentre io sto facendo qualcosa in applicazione. Ma penso che sia meglio solo per fare in modo che le query di lavoro, non so se è conveniente per misurare il carico di lavoro del server come questo. Profiler può anche salvare tracciato che è possibile analizzare in seguito, in modo che potrebbe funzionare.