2.3 – La fragmentation physique

doit ensuite contenir une plus grande quantité d’informations, alors il faudra qu’il demande à l’OS de nouvelles granules à lui adjoindre afin de gérer cette croissance.

Dès lors l’ensemble du fichier est constitué de granules éparses acquises au fur et à mesure des opérations de croissance. En effet, il y a fort peu de chance, surtout si l’activité de votre PC est intense, que ces granules soient contigües. Or, cette non contiguïté conduit à lire l’intégralité d’un fichier en sautant d’emplacement en emplacement ce qui dégrade singulièrement les performances de la lecture. Bien évidemment ce phénomène n’est pas grave s’il s’agit d’un fichier Word ! En revanche pour un fichier de base de données il en va tout autrement. Cette fragmentation est bien connue puisqu’un outil de défragmentation est présent dans la palette des outils systèmes de Windows.

La particularité d’un fichier de données d’une base, est qu’il est en permanence ouvert à l’usage exclusif du serveur SQL. Pourquoi ? Tout simplement parce que le serveur doit pouvoir à tout moment et sans préavis écrire des données. D’où un verrou d’écriture permanent dès que la base est active. Peut-on défragmenter un fichier de base de données fragmenté ? Oui, assurément. Mais pour cela il faut arrêter l’exploitation de la base, détacher le fichier de données de la base, procéder à la défragmentation au niveau de l’OS.

De plus, le chaînage interne effectué par SQL Server sur les pages du fichier de la base sera bouleversé. Il y a fort à parier qu’au redémarrage SQL Server mettra un certain temps avant de retrouver ses petits… Bref, un travail incompatible avec un service efficace et continu des données ! Le plus simple est donc de créer des fichiers de données d’une taille suffisante à absorber le volume de plusieurs années d’exploitation de la base de données lors de la création de celleci. Règle n°3 : créez des fichiers de taille fixe.