Discussion :

[nesswaw]

Bonjour,

J'ai une base qui fait 45Go quand j’exécute la requête suivante:

Code :

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

1
2
3
 
USE MaBase
EXEC sp_spaceused

Taille des fichiers:

- Base: 30Go
- Log: 16Go

Dans cette base j'ai fait une grande purge des enregistrements, via l'application qui exploite cette base

Cette nuit les backups de la base ainsi que des logs se sont fait.

Ce matin quand je vérifie les tailles, rien n'a bouger...même pas d'un KO...

Il y a juste "unallocated space" qui est passé de 8728 MB à 11928 MB

Que dois-je faire pour réduire la taille de ma base et des fichiers?
On m'as toujours dit qu'un shrink était déconseillé?

Merci d'avance

[SQLpro]

Dans cette base j'ai fait une grande purge des enregistrements, via l'application qui exploite cette base

Cette nuit les backups de la base ainsi que des logs se sont fait.

Ce matin quand je vérifie les tailles, rien n'a bouger...même pas d'un KO...

C'est parfaitement normal. Quand vous purgez un radiateur diminue t-il de volume ?

Il y a juste "unallocated space" qui est passé de 8728 MB à 11928 MB

Que dois-je faire pour réduire la taille de ma base et des fichiers?

Supprimez les espaces vide des fichiers via une commande DBCC SHRINK...

On m'as toujours dit qu'un shrink était déconseillé?

Oui, c'est stupide et contre performant....

Lisez ceci :
http://blog.developpez.com/sqlpro/p5..._fichiers_et_t
et en particulier le paragraphe intitulé "Pire ! C’est possible…"

Et pour parfaire votre culture :

[nesswaw]

Merci pour votre aide.

Donc faire DBCC SHRINK est égal à un simple shrink? Donc pas faire si je comprend bien?

Dans votre article, vous dites qu'il faut faire une base de taille fixe, si par exemple je fait une base de 1Go (aussi log à 1Go), et que dans 2 ans ma base fera 2Go, que va-t--il se passer?

Par contre pour le fichier de log, si atteint les 1 Go, il va se vider? Ou des problèmes de perf à cause que pas assez grand?

Merci pour ces explications

PS: J'ai déjà hésité plusieurs fois à acheter ce bouquin, je vais sauter le pas, ça va pas me faire de mal

[janlouk]

Dans votre article, vous dites qu'il faut faire une base de taille fixe, si par exemple je fait une base de 1Go (aussi log à 1Go), et que dans 2 ans ma base fera 2Go, que va-t--il se passer?

Si vous savez que dans 10 ans, votre DB fera 10 GB, alors il est conseillé de mettre cette taille afin qu'il y ait un minimum d'autogrowth. Mais rien ne vous empêche de mettre 2 Go avec un autogrowth de 500 MB.

Par contre pour le fichier de log, si atteint les 1 Go, il va se vider? Ou des problèmes de perf à cause que pas assez grand?

Il va se vider si vous faites un backup log, mais se vider ne veut pas dire se réduire (comme l'exemple du radiateur).

Ps : C'est un très bon livre, je l'ai, mais je dois prendre le temps de le lire . Mais les vidéos lors des JSS et techdays sont vraiment bien aussi. En voici une petite partie : http://www.datacrossroad.be/best-pra...l-server-2012/

[nesswaw]

Si vous savez que dans 10 ans, votre DB fera 10 GB, alors il est conseillé de mettre cette taille afin qu'il y ait un minimum d'autogrowth. Mais rien ne vous empêche de mettre 2 Go avec un autogrowth de 500 MB.

Comment savoir la taille dans 10ans pour un nouveau projet? C'est pratiquement impossible, le logiciel évolue, le nombre de personne qui l'utilise aussi, l'institution évolue, on ne peut savoir l'état dans 10ans, non? On peut estimer, mais tellement de paramètres rentrent en compte, que le risque d'erreurs est énorme, les surprises en informatique c'est la base du métier

Ma question est comment gérer cette erreur? Peut-on faire une base de 1Go et l'augmenter à 2Go si on voit qu'on va bientôt manquer de place?

Merci

[janlouk]

Oui bien sûr, difficile de savoir, mais en sachant ce qu'insert l'application qui rempli la DB, on peut faire une petite estimation. Rien n'empêche de commencer à 2 GB, mettre un autogrowth de 250 MB et voir dans 1 mois ou 2, l'évolution de la DB.

Si vous voyez qu'en 2 mois, l'espace utilisée est de 500 MB, vous savez que 2 GB ne sera pas assez. Encore une fois, c'est du best practice. Car lorsque la table grandit, cela peut provoquer des ralentissements, des verroux et donc des blocked process.

[janlouk]

Donc faire DBCC SHRINK est égal à un simple shrink? Donc pas faire si je comprend bien?

DBCC Shrink est la commande pour faire le shrink, c'est une autre manière que de le faire via l'interface de SSMS.

Il ne faut pas le faire si vous savez que votre DB grandira un jour ou l'autre. C'est ce que veut dire Frédéric, pourquoi diminuer la taille d'un fichier que l'on sait qu'un jour il reviendra à cette taille là.