Aujourd’hui petite précision sur les IO (vous savez ce qui préocupe les DBAs toute la sainte journée
)
Il existe deux types d’accés :
- Physical IO : Accès au disque pour récupérer les pages de données.
- Une fois récupérée la page est placée dans le Buffer Cache
- Logical IO : Accès direct à une page de données situé dans le Buffer Cache
Comment améliorer les performances ? En minimisant au possible les Physical IO.
- Avoir assez de mémoire (ouais c’est évident, mais faut bien le préciser
) - Optimiser l’architecture physique et logique de votre base (les index !)
- Optimiser vos requêtes pour éviter de trop avoir besoin de récupérer des page sur le disque
Comment faire pour “voir” les IO générés ?
SET STATISTICS IO ON

Ok, il fait 1240 Logical Read, pour 2 Physical Read
Vous noterez que Môôssieur ne récupère QUE 2 pages sur le disque alors que j’ai au préalable vidé les Buffers Cache.
Et bien il faut savoir que SQL SERVER utilise une technique de lecture anticipée (lors de la compilation de la requête) pour engranger des données en mémoire “Juste Au Cas Où” : Ce sont les Read-Ahead Reads
Je ré exécute cette requête, dans la foulée :
Là on remarque que SQL SERVER effectue bien ses lectures directement dans le cache SQL SERVER.
Que pouvez vous faire contre les Physical IO ?
Nous venons de voir que les Physical IO sont ceux qui coutent le plus cher. Mais que pouvez y faire ?
Et bien … RIEN ! (oui c’est balot)
Le seul moyen de réduire les IO Physical, c’est d’améliorer les IO Logical, enfin bref d’améliorer les IO en général !
Meilleurs requêtes, Plus de ram, Meilleurs indexs.
Quelles sont les outils d’investigations:
Profiler SQL

Notez que le profiler ne différencie pas les types d’IO (Physical, Logical, Read Ahead)
Vous avez donc une donnée qui représente les Logical Read.
DMV
Quelques DMV peuvent vous aider. Elles sont en général basées sur sys.sysprocesses :
Select db_name(sp.dbid) as ‘Database’
,cpu,physical_io
,[program_name]
,sql_handle,st.text
from sys.sysprocesses sp
cross apply
sys.dm_exec_sql_text(sp.sql_handle) st
where db_name(sp.dbid) not in (‘master’,'model’,'tempdb’,'msdb’)
order by cpu desc
Compteur de performances
Les compteurs relevés sont :
- % Durée d’inactivité
- % Temps d’écriture
- % Temps de lecture
D’une manière générale, le % d’inactivité doit être toujours le plus proche de 100%
A contrario, les % d’écriture et de lecture doivent être le plus proche de 0%

Ici on remarque que le Disque est soumis à rude épreuve, même s’il tient le choc (Les pics de durée d’inactivité n’atteignent pas 0% sur une longue durée)
Quoi d’autres ?
Il existe d’autres éléments, qui sont plus ou moins en rapport avec les IO :
- Amélioration des Index
- Fragmentation des index
- Pression mémoire
- Amélioration des procédures stockées et requêtes
- Nouveaux index etc …
Un véritable sacérdoce ces IO !! ![]()










