Version imprimable
Bonjour,
J'explique mon problème je souhaite faire une epuration de la base pour reduire la taille de cette derniere.
apres avoir supprimé un bon nombre de données je me rend compte que la base (fichier mdf) fait toujours la meme taille.
Je me demande donc si il y a pas une manip supplémentaire a faire qui peut etre comblerai des espaces mort ou autre...
Merci bcp
Effectivement il y a des mécanismes pour réduire la taille des fichiers de la base de données
Lien qui présente les déférences solution a utilisées
http://msdn.microsoft.com/fr-fr/libr...v=sql.90).aspx
C'est parfaitement normal et la réduction physique de la taille des fichiers est généralement une très mauvaise idée...
L'utilisation d'un SHRINK ne doit être entrepris que d'une manière tout à fait exceptionnelle (quand par exemple le disque est saturé et qu'aucune autre solution ne peut réduire l'encombrement du disque).
A lire sur le sujet :
http://blog.developpez.com/sqlpro/p5...fichiers-et-t/
A +
sql pro : ton lien est interessant, mais j'avoue que je comprend pas tres tres bien... l'idée me parait clair mais il aurait fallu que la base soit crée au prealable de cette facon non ??
comment faire quand on a une base deja trop grosse...
j'ai aussi compris pourquoi le dbshrink est pas recommandé mais s'il est fait une fois tous les 10 ans est-ce si grave ??
Une base de données étant par nature toujours en croissance, quel est l'intérêt de la dégonfler pour la regonfler ?
A part augmenter sensiblement les temps de réponse ???
A +
ben justement je veux la degonfler pour que la base reponde plus rapidement.
pour aussi avoir un gain de place...
elle va se regonfler ;-)Citation:
Envoyé par forsay1
c'est ce qu'on appelle "effet accordéon".
Si c'est un problème de performances sur la base il faut commencer par rechercher les causes du lenteur afin d'apporter une solution.
Mais c'est un problème d'espace disque, il faut voir comment repartir les fichiers de base de données sur d'autres disques
A+
probleme de place non je dirai pas ca...
mais l'editeur du logiciel qui exploite cette base m'a conseiller d'epurer les données pour augmenter la rapidité... mais si la taille de la base est toujours aussi grosse malgré l'epuration, les requêtes executées seront toujours aussi lente d'où l'idée de la compression
Ce dégonflage n'aura pas d'influence sur les performances. Ce sera même le contraire. Vous aurez de bien plus mauvaises performances globales !Citation:
Envoyé par forsay1
A +
que faire dans ce cas
Vous avez utiliser un outil de l'éditeur pour purger la base ?Citation:
Envoyé par forsay1
ou bien c'est vous qui aviez créer votre propre procédure de purge ?
Si le logiciel est toujours supporté par l'éditeur, il me semble que ce dernier devrait vous aider à trouver une solution durable à votre problème ? c'est leur job ! non ?
A+
alors j'ai fait sur une base test une purge avec le logiciel de l'editeur...
l'editeur oui devrait nous aider a ca sauf que l'editeur m'a dit de purger pour que justement les données consultées dans les requetes soit moins grande et donc augmenterai les temps de reponses...
et pour eux ce serait la seule solution... maintenant je lis dans les forums que ce n'est pas la solution...
le fait que le logiciel soit du coup tres lent me pose des problèmes car en effet il y a un temps ou la base etait 2 fois moins grosses le logiciel repondait rapidement aux requetes lancé par les utilisateurs... aujourd'hui ce n'est plus vraiment le cas
La gestion des performances d'une base de données se fait à différents niveau :
1) hardware :
a) la quantité de RAM (un SGBDR C/S travaille exclusivement en mémoire)
b) les disques et leur organisation (niveau de RAID, types d'agrégat...)
c) les CPU et leur mode (nombre, type, organisation)
2) modélisation
a) choix des types de données (préfèrez de l'ASCII plutôt que de l'unicode, préférez du CHAR que du VARCHAR pour les petites données...)
b) organisation des tables (évitez les tables obèses, cad plus de 20 colonnes)
c) faire des clefs primaires de qualité et d'éventuelles contraintes d'unicité
d) mettre des contraintes (et surtout CHECK et FOREIGN KEY)
3) codage
a) utilisez des procédures stockées plutôt que des requêtes ad hoc
b) évitez les curseur
c) évitez les tables temporaires
d) évitez les déclencheurs
4) physique
a) placer les bons index
b) maintenir les index et les statistiques
d) gérer les espaces de stockage.
Bref, un boulot de DBA !
A +
et comme je suis pas dba... mais que je m'occupe de la base par delegation...
ben je suis foutu lol
Bonjour Forsay,Citation:
Envoyé par forsay1
Ce que veulent te dire les autres c'est que réduire physiquement le fichier MDF ne va pas accélérer les temps de traitement --> Bien au contraire, cela va augmenter la fragmentation des données sur Disques.
Maintenant, ce que veux dire ton éditeur, c'est qu'il est possible de purger (ou supprimer des données trop ancienne par exemple ... qui ne servent plus mais que tu remontes pourtant dans tes requêtes).
Je ne sais pas si je suis assez clair :(
Grosso modo, ta base peut faire 100MB comme 10GIGa, tu peux avoir toujours le même nombre de lignes ou données à l'intérieur... La taille physique n'est pas importante (sauf manque d'espace disque).
Ce que tu dois faire c'est supprimer les données de la base et non réduire sa taille physique.
En espérant avoir pu vous aider ;)
oui oui c'est bien ce que j'avais compris...
bon ben je vais relancer une purge faire quelque test voir si effectivement les choses changent...
en revanche j'ai vu qu'une reindexation peut etre utile dans ce cas...
dois-je en faire une apres épuration ?
AVANT !!!, car après vous aurez à nouveau de l'espace libre !
Mais encore une fois, réduire les espaces vide est contre performant !
A +