Discussion :

[genius4evers]

Bonjour
Comment peut-on résoudre le problème d'augmentation du taille de la BD.
Y a t-il une requête pour réduire la taille ?
Merci

[Boubou2020]

*Défragmenter vos index puis faire un shrinkfile(ne pas faire le SHRINK que sauf si vous devez avoir besoin d'espace disque)

*La compression des données réduit aussi le stockage de base de données

[SQLpro]

Bonjour
Comment peut-on résoudre le problème d'augmentation du taille de la BD.
Y a t-il une requête pour réduire la taille ?
Merci

Tout dépend si l'augmentation est liée aux données ou aux transactions.
Que donne les deux requêtes suivantes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT DB_NAME(database_id), size * 8 AS TAILLE_KO, type_desc, name
FROM   sys.master_files;
 
DBCC SQLPERF(LOGSPACE);

A +

[genius4evers]

Après l’exécution du cette req , je trouve pas le nom du mon DB dans le resultat.
mon problème est liée aux transactions.

[Invité]

*Défragmenter vos index puis faire un shrinkfile(ne pas faire le SHRINK que sauf si vous devez avoir besoin d'espace disque)

C'est quoi ça ? Tu défragmentes tes indexes puis tu les fragmentes juste après ?
Tu ranges la chambre des enfants puis tu lâches une classe d'enfants surexcités dedans... Ça ne me semble pas super efficace !

[Boubou2020]

SHRINK DATABASE peut faire gagner de la place au niveau physique, à condition que les données soient défragmentées.
Avant il faut donc les défragmenter....


Ça ne me semble pas super efficace !---->ne pas faire le SHRINK que sauf si vous devez avoir besoin d'espace disque

[SQLpro]

Le SHRINK est une opération parfaitement stupide et ne doit être utilisée qu'en cas d'urgence absolue !

A +

[elsuket]

J'aurais plutôt dit : le SHRINK est à utiliser dans deux cas :

• Après un nettoyage / archivage massif de tables qui a pour conséquence une réduction importante de la taille de quelques tables qui étaient très volumineuses auparavant, et qui occupaient une bonne part de la taille du fichier de données;
• Lorsqu'on a réalisé une mise à jour de données sur de larges tables sans batcher la mise à jour : cela peut avoir pour conséquence un grossissement exceptionnel de la taille du fichier du journal des transactions;
• Lorsqu'on manque d'espace disque : c'est le cas d'urgence absolue.

@++

[SQLpro]

J'aurais plutôt dit : le SHRINK est à utiliser dans deux cas :

• Après un nettoyage / archivage massif de tables qui a pour conséquence une réduction importante de la taille de quelques tables qui étaient très volumineuses auparavant, et qui occupaient une bonne part de la taille du fichier de données;
• Lorsqu'on a réalisé une mise à jour de données sur de larges tables sans batcher la mise à jour : cela peut avoir pour conséquence un grossissement exceptionnel de la taille du fichier du journal des transactions;
• Lorsqu'on manque d'espace disque : c'est le cas d'urgence absolue.

@++

J'y rajouterais :

• lorsqu'une importante restructuration des tables de la base est effectuée

A +