[sql server 2005] tempbd pleine, arrêt de procédure

Salut
Je doit remplir une table [données agrégées] à partir d’une autre table [données brutes].
La tables [données brutes] contient le chiffre d’affaire de la société la quantité de ventes et le budget (quantité et montant) par mois.
Dans la table [donnée agrégées], je dois garder les même données et rajouter les données cumulés par année jusqu’au mois courant, ainsi que ces même données pour les années N-1 et N-2 en rajoutant les totaux pour ces deux année.
Au début, pour remplir la table [données agrégées], j’utilisais une requête toute con :

Code:

---

1 2 3 4 5 6

insert into [données agrégées] (…) select … from [données brutes] (…)

---

mais en faisant cela au bout d’une heure (je faisais autre chose pendant ce temps, rassurez-vous) j’ai une erreur me disant que la table tempdb était pleine à craquer et que l’exécution de la requête s’est arrêté à cause de cela :(
j’ai donc créé des tables intermédiaires (une pour l’année courante, une pour l’année N-1 et une autre pour l’année N-2) dans une procédure stockée que je remplie et qui me servent à remplir la table principale. Ça a marché au début mais maintenant j’ai encore ce message d’erreur (mais au bout de 20 minutes cette fois) :

Citation:

---

Msg 9002, Niveau 17, État 4, Procédure majInfSec, Ligne 233
Le journal des transactions de la base de données 'tempdb' est plein. Pour savoir pourquoi il est impossible de réutiliser de l'espace dans le journal, consultez la colonne log_reuse_wait_desc dans sys.databases.
Msg 9002, Niveau 17, État 4, Procédure majInfSec, Ligne 233
Le journal des transactions de la base de données 'tempdb' est plein. Pour savoir pourquoi il est impossible de réutiliser de l'espace dans le journal, consultez la colonne log_reuse_wait_desc dans sys.databases.

---

Si vous connaissez un moyen pour optimiser les ressource dans mon cas, aidez moi, ça fait un moment que je rame ...

La requête

Code:

---

select log_reuse_wait_desc from sys.databases

---

Me donne le résultat suivant :

Code:

---

1 2 3 4 5 6 7 8 9

log_reuse_wait_desc ------------------------------ NOTHING NOTHING NOTHING NOTHING NOTHING ACTIVE_TRANSACTION NOTHING

---

PS:à la ligne 233 dema requête il y a juste un point virgul (représentant la fin de la création de la table temporaire pour l'année N-2 et le début du remplissage de la table temporaire à l'année courante

PS2:j'utilise le même principe pour une autre table et ça fonctionne (mais je doit avouer qu'il y a moitier moins de données^^)

Un sujet parlant de l'utilisation de la tempdb:

http://sqlserver2000.databases.aspfa...happening.html

comme il est indique dans l'article, verifie que ton journal est en mode de recuperation simple.
utilise la commande ALTER DATABASE tempdb SET RECOVERY SIMPLE si ce n'est pas le cas.
si ton journal est en mode de recuperation simple, je ne vois pas d'ou vient le probleme.

si tu créés ta table en question dans la base tempdb (?) utilise plutôt :

Code:

---

1 2 3 4

SELECT … INTO [données agrégées] (…) FROM [données brutes] (…)

---

ce qui réduit drastiquement les entrées dans le journal.

Mais si tu fais des agrégations, il y a grandes chances que ce soit ton group by ou ton order by (je ne le vois pas dans ton code, est-ce que tu en utilises un ?) qui sature ta tempdb ...

est-ce que c'est bien le code complet ?

Salut,
Le RECOVERY de tempDB était bien en mode « SIMPLE » :(
Mais comme vous l’avez dit, dans ma procédure, il y a 7 jointures externes et 8 jointure naturelles et 9 « group by ». ça doit être ça qui prend de la place,
Mais je ne fait pas tout ça en même temps, il faudrait donc un moyen pour purger tempDB après chaque grosse opération,
Je n’en suis pas très sur, mais si cela implique un commit à la fin de chaque opération, ce n’est pas vraiment une bonne chose, je ne pourrais plus faire de rollback en cas de problème …
Autre chose, je ne crée pas les tables temporaires dans tempDB pour éviter que ne prenne beaucoup de place. Je les crée directement dans la base de données principale que j’utilise, puis je les vire à la fin de la procédure.
Faut-il quand même que je fasse

Code:

---

SELECT (…) INTO (…) FROM (…)

---

?

salut, c'est encore moi ;)
en fait, j'ai pu régler mon problème en séparant mes insertions et en utilisant encore plus de tables intérmédiaires. Cela minimise les grosses jointures et les gros regrouppement, ce qui permet à chaque fois de libérer l'espace non utilisé dans tempDB. et à la fin, je fait 9 jointures naturelles, mais celleci ne demandent pas beaucoup d'espace...
merci pour vos interventions, ça m'a beaucoup aidé