Discussion :

[freestyler]

Bonjour,

j'ai une base de données dont la taille augmente indéfiniment.
j'utilise des tables temporaires dans mes requêtes que je supprime (DROP) une fois terminé.

Cependant, la taille de ma base ne cesse pas d'augmenter et le fait de supprimer les tables ne réduit pas sa taille.

Ya des options pour remédier à ça ?
Merci

[Ptit_Dje]

Hmmmm... Arrêter d'y introduire des données... ^^

[freestyler]

Trés amusant..

Pourquoi une table supprimée occupe encore de l'espace sur le disque?

[Ptit_Dje]

Je ne vois pas ce qu'il y a d'amusant, dans votre définition vous dites que la base de donnée croit indéfiniment, ce qui est effectivement le cas d'une base de donnée en activité dans laquelle on charge des données, si aucun archivage n'est prévu. Soyez plus spécifique lorsque vous posez une question et l'on pourra mieux vous répondre

Maintenant une base de donnée à un taux de croissance prédéfinit, que ce soit en MB ou en % vis à vis de sa taille.
Une fois le fichier "agrandi", l'espace disque reste reservé et vide, qu'il y aie ou pas des données qui remplisse tout l'espace... Une fois tout l'espace occupé, un accroissement se produira et ce indéfiniment s'il n'y a pas de limite de croissante spécifiée.

Pour récupérer l'espace non utilisé, faites un shrink...

[freestyler]

Plus précis que ça ?

j'ai une base de données dont la taille augmente indéfiniment.
j'utilise des tables temporaires dans mes requêtes que je supprime (DROP) une fois terminé.

Je charge des données OUI.. mais je supprime les tables TEMP Aprés.
Cependant, la taille de la base ne se réduit pas.


C'est ça ma question !!!

[Jinroh77]

Que fait tu de ces données ? Juste un passage en table temporaire, sans alimenter de vraies tables au passage ?

Sinon tu peux regarder l'espace disque réservé à ta base mais non occupé.
Clic droit sur la base\Propriétés\Espace innutilisé.

[freestyler]

si j'alimente des vraies tables

mais je les supprime à la fin

[Ptit_Dje]

Tu alimentes des vraies tables pour les supprimer ?!
Je suis désolé, je ne te comprend pas.
Petite remarque pour les tables temporaires : elles peuvent aussi très bien se trouver dans tempdb !

[elsuket]

Bonjour,

Fressetlyer, c'est peut-être aussi votre log de transaction qui gonfle ...

[SQLpro]

Il n'y a aucun intérêt à réduire les fichiers d'une base de données lorsqu'elle est en croissance automatique. Par analogie, imaginons que vous soyez en train de construire un parking... Vous venez de terminer de bétonner le premier emplacement de voiture, un véhicule peut maintenant s'y installer. Bien. La voiture se gare... AU bout de 3 heures, la voiture part. Allez vous prendre votre marteau piqueur pour détruire le béton ???
Avouez que si vous faisiez cela on vous traiterait d'imbécile !

Alors pourquoi voulez vous qu'un SGBD relationnel qui a dû structurer ses fichiers pour accepter des données, décide subitement de détruire ce qu'il vient de faire, parce que quelques lignes se sont volatilisées ?
Pensez que tout ceci est optimisée. Ce qui a été fait n'est plus a faire et tout le monde gagne du temps. Mais si vous voulez des performances lamentables, alors n'hésitez pas... Prenez le marteau piqueur qui s'appelle DBCC SHRINKFILE dans SQL Server, et cassez les fichiers....

De plus, sur le plan général, une base de données, devrait avoir été créée avec un taille fixe égale au volume des données attendue sur 3 à 5 années. Lisez l'article que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro?ti..._fichiers_et_t

A +

[freestyler]

1- ce n'est pas mon log de transaction

2- Prenons l'exemple du parking : Si une voiture part, elle devrait libérer sa place, non? et bien c'est pas le cas et personne ne semble comprendre le post ici.

Tout ce que je dis :

J'ai un script.
Dedans, je fais plusieurs CREATE TABLE.
A la fin du script je fais autant de DROP TABLE que de CREATE.

Je pars avec une base a 1 giga
A la fin du script la base (MyDB.mdf) atteint les 10 gigas.

Pourtant, physiquement, la base n'a pas changé.

[Jinroh77]

Lorsque ta base est défini avec une croissance de taille automatique, quand tu la rempli, la base prend du volume.
Ensuite tu supprimes tes tables, mais dans la logique d'utilisation d'une BDD, SQL Server n'a aucun raison de réduire la taille de la base.

Si tu veux la réduire, c'est à toi d'utiliser une commande shrink. Mais si tu fais cela plusieurs fois (remplir, vider) comme cela a été dit plusieurs fois, il n'y a pas vraiment de raison de vider la base.

[Invité]

@freestyler:
Le fait de faire des DROP TABLE ne libère pas l'espace disque. L'espace disque alloué à une base n'est restitué au système que suite à des opération de type SHRINKFILE ou SHRINKDATABASE.

Ensuite, pourrions-nous voir :
1. le code relatif aux CREATE TABLE et DROP TABLE.
2. le résultat d'un EXEC sp_helpdb 'tabase' avant et après l'exécution de ton script, ainsi qu'un DBCC SQLPERF(logspace)

De plus, quel sont les options de ta base de données, notamment le recovery mode ?

Avec ces infos, nous y verrions peut-être plus clair....

[SQLpro]

Je pars avec une base a 1 giga
A la fin du script la base (MyDB.mdf) atteint les 10 gigas.

Non, ce n'est pas votre mdf qui augmente de taille, mais votre ldf qui est le fichier du journal de transaction (JT). Toute opération de manipulation de données en écriture : CREATE, ALTER, DROP, INSERT, UPDATE, DELETE est une transaction et à ce titre les informations des données avant et après sont stockées dans le JT. C'est pourquoi, lorsque vous droppez une table, celle-ci et avec toutes ses données est inscrite dans le journal...

A +

[freestyler]

On dirait que personne n'a l'air de comprendre ..

Non c'est le fichier MDF qui augmente de taille et non pas le LDF... et comme j'ai précisé avant, ce n'est pas le log de transaction.


ce n'est pas exactement des CREATE TABLE, mais des :

Code :

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

1
2
3
4
 
Select ...
into TEMP_table
from ...

suivi d'un

Code :

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

DROP TEMP_table

que je répéte une dizaine de fois, avec des requêtes assez complexes (plusieurs jointures)


Comme je l'ai aussi précisé, le fichier MDF avant exécution a pour taille 1 Giga. Apres exécution, il dépasse les 10 Gigas. Le fichier LDF augmente (de 100 meg à 300 meg)

Recovery Mode (Page Verify -- CHECKSUM) si c'est ca que vous voulez!

AutoShrink : False



Tout ce que je voulais savoir :
Ce comportement est il normal?
Si oui, que faut-il faire pour ne pas avoir ce probléme quand je lance mon script une prochaine fois?

(Et Merci de faire confiance à ce que je publie dans mon post)

Merci

[Jinroh77]

Comme expliqué et demandé plusieurs fois, as-tu essayé un shrink sur la base et les fichiers de données ?

Pour le comportement, oui c'est normal si la base est en Croissance Automatique. Dès qu'elle a besoin de place elle en prend mais on ne lui demande pas automatiquement de la restituer.

[Invité]

Recovery Mode (Page Verify -- CHECKSUM) si c'est ca que vous voulez!

Non, ça, c'est pas le recovery mode. Les valeurs possibles sont:

• SIMPLE
• BULKED LOGGED
• FULL

[SQLpro]

Pour ton MDF qui augmente c'est normal... LE SELECT ... INTO que tu fais créée les tables dans la base de données courante....
C'est une manière de faire assez mauvaise. Soit tu utilise des variables table, soit tu utilise des tables temporaires, mais faire des tables dans la base est une fort mauvause idée. De plus en faire beaucoup est une idée exécrable.

Aujourd'hui avec SQL Server 2005 les expressions de table, les requêtes récursives et les fonctions de fenêtrages il n'y a aucun besoin de stocker des résultats intermédiaires puisque tout traitement ensembliste aussi complexe qu'il soit peut être réalisé en une seule requête SQL...

La prochaine fois poste l'intégralité de ton code... Tu évitera de nous faire perdre du temps et tu gagnera toi aussi du temps !
En postant ton code tu respectera aussi la charte de postage...

A +

[freestyler]

je ne peux vraiment pas poster mon code.. sécurité oblige, et puis il s'agit de plusieurs lignes de codes (un millier..)

Je doute fort que je puisse m'en sortir avec une seule requête SQL, et puis les tables temporaires me facilitent d'autres requêtes aprés surtout que les tables que je cree contiennent bp moins de données que le table principale (fichier texte source de 5 gigas). Ca limite mon temps de traitement tres sensiblement.

Tu dis :

Soit tu utilise des variables table, soit tu utilise des tables temporaires,

je suis intéressé par le comment de la chose..
tu peux m'expliquer vite fait en gros stp .. ou me diriger vers un lien

Merci beaucoup

[SQLpro]

Je doute fort que je puisse m'en sortir avec une seule requête SQL,

Je prends le pari à 100 000 euros !

et puis les tables temporaires me facilitent d'autres requêtes aprés surtout que les tables que je cree contiennent bp moins de données que le table principale (fichier texte source de 5 gigas). Ca limite mon temps de traitement tres sensiblement.

Sauf que vous ne faites pas des tables temporaires, mais vous instanciez des tables dans la base. Pour créer des tables temporaires il faut les prénommer avec un suffixe dièse. Exemple :
CRFEATE TABLE #toto.

Ensuite instancier réellement des tables, qu'elles soient temporaires ou non, suppose des écritures sur le disque. Alors qu'en faisant cela en une seule requête tout se passe en mémoire. Grosso modo vous pensez gagner du temps en faisant votre sauce, mais en réalité vous multipliez par un facteur 1000 ou plus les temps de réponse ! (la différence de vitesse intrinsèque entre disque et RAM est d'un facteur 1 million)

A +