Tirer le meilleur parti de votre stockage pour SQL Server

Il convient avant toute chose d’avoir une bonne compréhension du profil de l’application que l’on souhaite connecter à SQL Server. En effet, la principale difficulté avec tout moteur de bases de données est d’établir des règles de dimensionnement.

Le profil des Entrées/Sorties (E/S) disques est fonction de l’application connectée à SQL Server. Même si chaque application peut avoir des comportements différents, elles peuvent malgré tout être classées dans deux grandes familles : les applications transactionnelles et les applications décisionnelles. Les applications transactionnelles génèrent des d’E/S à accès aléatoire avec un ratio lecture/écriture approchant les 60/40.

La taille des accès est souvent de l’ordre de 8 Kilo octets. Les applications décisionnelles ont un profil d’E/S de type séquentiel avec des accès en lecture pendant les phases de construction de cubes par exemple et d’écriture pendant les phases de chargement. La taille des accès est souvent de l’ordre de 64 Kilo octets, voire beaucoup plus. Le profil des logs est également à considérer : une application transactionnelle génère un gros volume de log (écriture séquentielle) contrairement à du décisionnel où les logs sont assez peu utilisés.

D’autres opérations de maintenance ou d’administration peuvent solliciter également le stockage. Celles-ci doivent être prises en compte. Il s’agit de :
 

• la sauvegarde et la restauration
• la génération d’index
• la vérification de l’intégrité d’une base
• l’opération de « checkpointing » (écriture sur disque des pages modifiées)

   

La configuration du stockage devra donc être alignée sur le profil de l’application et surtout sur le niveau de service attendu.