base de données ENORME

[xavierm]

Salut a tous,
Je cherche une solution a un problème qui risque d'être très ennuyeu pour moi d'ici peu.
J'ai une appli Windows qui fonctionne avec une basse de données SQL SERVER 8 sous Windows 2k3 SP3.

Le problème c'est que ma base de données augmente de façon importante de jour en jour. Aujourd'hui il ne me reste que 4 Go de dispo sur le disque et je pense que d'ici 1 mois (ou 2 grand max) je n'aurai vraiment plus de place.
De plus j'ai l'impression que ca ralenti ma base de données et que ca me provoque certains bug encore inexpliqués

Si quelqu'un a une idée ca serait le bienvenu

[arapaho]

Et quelle est la question ?

[xavierm]

Oups ..... pardon
en fait je voudrais reduire la taille de ma base de données.
Mon fichier de log (LDF) ne fait que 1Mo alors que le fichiers de base de données (MDF) lui fait 58Go
et comment eviter qu'elle grossise autant

[arapaho]

Court terme:
Sql server étant ce qu'il est, et ayant les liens de parentés avec les technos microsoft, il se peut fortement que les données écrites soient fragmentées: il serait de bon ton de passer un bon petit coup d'outil de défragmentation (sql étant coupé à ce moment).
Ensuite pour éviter que le phénomène de fragmentation se reproduise trop souvent, la croissance automatique doit être en mesure de croître la taille allouée de 12-15% d'un seul coup: cela évite une trop grande fragmentation.

Moyen terme:
Déjà il serait bon de pointer ce qui est "gros". A savoir, quelles tables, quelles données. Grossièrement: est-ce que la taille utilisée sur disque correspond correctement à celle des données utilisées. Il existe un paramètre "d'auto-réduction" (je ne me rappelle plus la dénomination exacte) qui permet de réduire dynamiquement la taille allouée sur le disque (inverse de l'attitude expliquée en "Court Terme").
Apparemment, dans ton cas, seule la croissance dynamique est active. Il te faut donc réduire la taille du fichier MDF s'il ne correspond pas à la taille réelle des données stockées. Les commandes magiques sont SHRINKDATABASE ET SHRINKFILE. Attention toutefois, ce n'est pas une opération bénigne: documentation à propos de ces commandes et sauvegarde sont de rigueur.

Long terme:
Passer sur du PostgreSQL ou à la limite du Oracle. Ne pas utiliser SQL Server sans admin SQL Server. (pardon)

[Franck78]

Salut,

Nonobstant la doc ou un bon support de cours sql-server, le gars qui a écrit "l'appli" doit bien avoir quelques idées sur comment rajeunir la base! Voire même quelques petites procédure stockées Ou même une appli débuggée

Interrogez-le aussi!

Bye

[xavierm]

salut a vous et merci pour vos réponses.

effectivement j'ai une croissance automatique de ma base de données qui est de l'ordre de 10%
J'ai d'identifier quelle etait ma table qui prenait le plus de place, ainsi que la taille de toute mes autres tables.
J'ai un écart de 5Go entre la taille réel des données stockés et la taille de mon fichier MDF.

Par contre quelque chose que je ne comprend pas. La table qui prend le plus de place a 30Go de reservé pour un data de 4.5Go seulement

je suppose que l'on doit bien pouvoir modifier la taille qui doit etre réservé pour ce champ...

[arapaho]

Et quelle est la question ?

[xavierm]

et bien la question c'est de savoir si il est possible de modifier la taille qui doit etre réservé pour ce champ

[Franck78]

Même "access" sait rédéfinir le type d'une colonne. Alors sql-server....
La vraie question est pourquoi le développeur a choisi ce type à priori "trop large". Pour ne pas avoir à trainer une donnée variable (image?,...) à l'extérieur de la base peut être? En tout cas, vu le niveau débutant de tes question, je doute très fort que tu puisses y rémédier.

Alors je repose ma question: pourquoi ne pas dialoguer avec l'auteur???

[xavierm]

Pour l'auteur c'est fait... il est étonné de voir que cette table occupe 4 fois sa taille réelle!!!
Je suis donc en train de chercher.
C'est un table de log (que je vais purger mais ce n'est pas le propos de la question).

vu le niveau débutant de tes question, je doute très fort que tu puisses y rémédier

Je vais donc me débrouiller seul et revenir une fois que j'aurai trouvé la solution.
Je n'ai pas encore eu réellement le temps jusqu'a présent d'administrer cette base de données et une base de données SQL server en générale.
Donc je pense que tu as de la chance car tu es devenu expert du jour au lendemain sans que personne ne t'explique......

Même "access" sait rédéfinir le type d'une colonne. Alors sql-server....

je ne veux pas redéfinir le type de mes colonnes ..... Je veux simplement comprendre pourquoi cette table occupe 4 fois sa taille réelle.....
Je pense que si j'en étais à savoir comment redéfinir les colonnes je n'aurais pas beaucoup avancé sur ma parti dev de l'appli....


Pour info je pense que je vais migrer ma base sur un server de test a coup de DTS et je vais voir comment cette table se comporte

[arapaho]

Pour l'auteur c'est fait... il est étonné de voir que cette table occupe 4 fois sa taille réelle!!!
Je suis donc en train de chercher.
C'est un table de log (que je vais purger mais ce n'est pas le propos de la question).

Une table de log. Une explication parmis tant d'autre: il se peut que beaucoup d'enregistrements soient écrits par salve pour être supprimés par la suite. Ce qui aurait pour effet de déclencher automatiquement la croissance dynamique du fichier concerné. Vu que la réduction automatique n'est pas activée, le fichier garde sa taille, jusqu'à la prochaine croissance. Réduire la taille doit être réalisable avec les commandes que je t'ai donné au dessus.

vu le niveau débutant de tes question, je doute très fort que tu puisses y rémédier

Je vais donc me débrouiller seul et revenir une fois que j'aurai trouvé la solution.
Je n'ai pas encore eu réellement le temps jusqu'a présent d'administrer cette base de données et une base de données SQL server en générale.
Donc je pense que tu as de la chance car tu es devenu expert du jour au lendemain sans que personne ne t'explique......

On souffle et on se détend. Tu viens sur un forum pour résoudre un problème, ce qui est absolument normal. Par contre ce serait impeccable si tu pouvais être plus précis dans ta demande: champs, tables, base de données, etc, j'avoue que je me perds un peu dans tes demandes (qui plus est, ça fait bien 6 ans que je n'ai pas fait de sqlserver).
Si on souhaite être précis sur les termes à employer, la notion de colonnes n'existe pas dans une table. Donc même un expert peut se tromper dans les termes qu'il utilise

Il serait de bon ton de reprendre les _champs_ de cette table ainsi que leur type afin de faire apparaître un probable "loupé" au niveau de la définition.

[Franck78]

Avant d'affubler sql-server d'un nouveau bug on va d'abord incriminer le développeur qui n'a pas envisagé un cas bizarroîde d'utilisation par un client (toi).
Mais pour ça il faut bien cerner le problème. Hors tes explications sont vraiment légères. A part être étonné, il fait quoi le développeur? C'est quand même lui le mieux placé pour diriger une investiguation non?

Le mieux que tu auras ici est une réponse du type "Lance une garbage collection".
En gros ca donne ça:
http://sqlserver2000.databases.aspfaq.c ... erver.html
google "sql server shrink data"

Mais rien de définitif. Cela recommencera. Le plus dur étant de trouver pourquoi pour le corriger.


@arapaho
je ne sais pas si 'columns' est censé avoir ou non une signification précise. On tout cas ni plus ni moins que 'raw' alors
SELECT AVG(Age) FROM Persons ;

[arapaho]

@arapaho
je ne sais pas si 'columns' est censé avoir ou non une signification précise. On tout cas ni plus ni moins que 'raw' alors
SELECT AVG(Age) FROM Persons ;

s/raw/row/
Oui oui, et là tu parles anglais. En français, on parle simplement de champs et d'enregistrements. C'est parce que l'anglais est au français ce que le PHP est au C, c'est à dire un langage "faiblement typé" entre autres. :p