> Tech > 2.3 – La fragmentation physique

2.3 – La fragmentation physique

Tech - Par iTPro - Publié le 24 juin 2010
email

Car l’autre phénomène désagréable et auquel il est difficile de remédier, c’est la fragmentation physique du fichier. Lorsque l’on crée un fichier, quel qu’il soit, il est ordinairement créé avec une taille minime, en fait la plus petite taille possible en regard des données à y stocker. Si ce fichier

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.

Téléchargez gratuitement cette ressource

IBMi et Cloud : Table ronde Digitale

IBMi et Cloud : Table ronde Digitale

Comment faire évoluer son patrimoine IBMi en le rendant Cloud compatible ? Comment capitaliser sur des bases saines pour un avenir serein ? Faites le point et partagez l'expertise Hardis Group et IBM aux côtés de Florence Devambez, DSI d'Albingia.

Tech - Par iTPro - Publié le 24 juin 2010