Εφόσον ο counter αυτός κρατιέται γύρω στο 95% τότε το caching δουλεύει μια χαρά.
Τώρα, το caching αυτό γίνεται από έναν μηχανισμό που λέγεται read-ahead ο οποίος βάζει στην cache αυτά που πρόκειται να ζητήσεις. Δεν βάζει τα πάντα ώστε να χρειάζεσαι μνήμη ίσα με το μέγεθος της βάσης, απλά μαντεύει τι θα ζητήσεις βάσει του query που στέλνεις. Εκεί είναι και η όλη "μαγκιά" του μηχανισμού (ο οποίος τρέχει σε διαφορετικό thread). Να μαντεύει σωστά.
Μπορείς να δεις αυτή τη συμπεριφορά όταν τρέξεις την εντολή SET STATISTICS ΙΟ μέσα από τον query analyzer και κατόπιν δώσεις τα queries που σε ενδιαφέρουν. Θα παρατηρήσεις ότι το output θα είναι κάτι του στυλ
Table xxxx. Scan count A, logical reads B, physical reads C, read-ahead reads D.
Αρχικά, διάβασε στα Books On Line για το τι κάνει η SET STATISTICS ΙΟ. Κατόπιν παίξε λίγο γράφοντας μερικά queries να δεις πως συμπεριφέρεται ο SQL Server. Γράψε το ίδιο query δύο φορές να δεις πάλι τι γίνεται. Ανα πάσα στιγμή, μπορείς να κάνεις reset την cache με τις εντολές DBCC FREEPROCCACHE και DBCC DROPCLEANBUFFERS (προσοχή γιατί στο production σύστημα, ειδικά αν έχεις μεγάλους πίνακες με πολλά data, οι χρήστες θα δουν καθυστερίσεις στην εκτέλεση των queries τους).
Vir prudens non contra ventum mingit