Logs TempDB ne font que grossir

Un autre moyen de voir comment est utilisé tempdb est de passer par la vue sys.dm_db_file_space_usage qui donne une idée de l'utilisation de cette base :

Code:

---

1 2 3 4 5 6

SELECT SUM(unallocated_extent_page_count) * 8. / 1024 AS unallocated_space_MB, SUM(version_store_reserved_page_count) * 8. / 1024 AS version_store_space_MB, SUM(user_object_reserved_page_count) * 8. / 1024 AS user_objects_space_MB, SUM(internal_object_reserved_page_count) * 8. / 1024 AS internal_objects_space_MB FROM sys.dm_db_file_space_usage

---

++

Pour l'instant, vous pouvez, vider le journal de transaction de la base en planifiant la requête ci-desous via sqlagent :

Code:

---

1 2 3 4

backup log tempdb with no_log go dbcc shrinkdatabase(tempdb) go

---

Citation:

---

Envoyé par mikedavem

Un autre moyen de voir comment est utilisé tempdb est de passer par la vue sys.dm_db_file_space_usage qui donne une idée de l'utilisation de cette base

---

On ne verra pas le journal, on ne voit que les fileid <> 2

Le début du fn_dblog (1430 premiers log records) montre qu'il y a eu 108 begin tran et 106 commits (aucun rollback). Si on extrapole on peut supposer que si l'ensemble du workload est de même nature, dans ce cas le journal contient de nombreuses petites transactions validées. La question c'est pourquoi il n'y a aucun checkpoint sur 26Gb de log records. Tiens d'ailleurs qu'est-ce que ça donne si on lance un checkpoint dans tempdb ? et qu'est-ce que renvoie dbcc loginfo('tempdb'), combien de VLFs ont un statut à 0 et combien ont un statut à 2 ? (<- faire le dbcc loginfo AVANT de faire un checkpoint :-)

Dans l'absolu il faudrait pouvoir faire le compte des transactions ouvertes / fermées dans tout le journal mais je ne me vois pas lui faire faire un select group by sur 26Gb sans compter le verrouillage que ça suppose d'inspecter une structure de cette taille.

Citation:

---

Envoyé par dbaffaleuf

Si on extrapole on peut supposer que si l'ensemble du workload est de même nature, dans ce cas le journal contient de nombreuses petites transactions validées. La question c'est pourquoi il n'y a aucun checkpoint sur 26Gb de log records.

---

Intéressant peut être un petit tour à faire du côté du sp_configure... Que donne :

Code:

---

EXEC sp_configure 'recovery interval';

---

Si cela ne passe pas :

Code:

---

1 2 3

EXEC sp_configure 'show advanced options', 1; GO RECONFIGURE

---

Puis refaire.

A +

Effectivement David, à y réfléchir cela ne sera pas vraiment d'une grande utilité pour mb10.

En réfléchissant à tête reposée après le boulot et en lisant ton dernier post je me suis rappelé de quelques fondamentaux. En effet, il faut savoir qu'un CHECKPOINT pour tempdb ne se produit que lorsque celui-ci se remplit à 70% et n'est pas concerné par le recovery interval. A noter également : un CHECKPOINT initié depuis le moteur pour tempdb a une priorité plus faible que les CHECKPOINT inititiés sur les bases de données utilisateurs. Cela signifie que le CHECKPOINT de la base tempdb ne s'exécutera qu'après que les CHECKPOINTS des bases de données utilisateurs se soient terminés eux-mêmes.

Il faudrait donc vérifier que le journal de tempdb se vide quand il rempli à 70%.
Autre moyen également est d'initier un CHECKPOINT manuel comme tu l'as mentionné.

++

Bonjour,

Effectivement, je me suis rendue compte que la taille des log de la TempDB est redescendu à 3% hier durant l'après-midi.

Cela explique tout.
Merci de votre aide.

Cordialement.

Encore une fois c'est pas la taille du log, mais le taux de rempliassage. Le taille restant fixe !

A +

Citation:

---

Envoyé par dbaffaleuf

La question c'est pourquoi il n'y a aucun checkpoint sur 26Gb de log records

---

Effectivement c'est assez bizarre.
Néanmoins le résultat produit par fn_dblog contient bien un événement LOP_BEGIN_CKPT puis LOP_END_CKPT.
En revanche par la suite, rien ...

Citation:

---

Envoyé par mb10

Effectivement, je me suis rendue compte que la taille des log de la TempDB est redescendu à 3% hier durant l'après-midi.

Cela explique tout.

---

Cela n'explique par ce qui occupe autant de place dans votre fichier du journal des transactions, ni son volume !

@++ ;)

Citation:

---

Envoyé par elsuket

Néanmoins le résultat produit par fn_dblog contient bien un événement LOP_BEGIN_CKPT puis LOP_END_CKPT.

---

Il n'y a toujours qu'un seul LOP_BEGIN_CKPT et un seul LOP_END_CKPT en tout début dans les journaux en mode simple.

Citation:

---

Cela n'explique par ce qui occupe autant de place dans votre fichier du journal des transactions, ni son volume !

---

Une base tempdb qui peut être fortement utilisé par exemple.
J'ai exactement le même symptôme chez un de mes clients qui utilise beaucoup les objets temporaires, les jointures, les opérations de regroupement et de tri ...

++

@dbaffaleuf : Merci !

Citation:

---

Envoyé par Mikedavem

J'ai exactement le même symptôme chez un de mes clients qui utilise beaucoup les objets temporaires, les jointures, les opérations de regroupement et de tri ...

---

Pour les JOIN, ORDER BY et GROUP BY, je dirai qu'on ne peut pas faire grand chose, et ma mauvaise foi me pousse à dire que les tables temporaires, les variables de type TABLE, et nos amis les curseurs en sont responsables si l'on utilise pas de transaction de niveau d'isolation SNAPSHOT.

Je n'ai pas encore vu cela poser un problème chez mes clients (j'en ai peu, mais bon ... :))

La taille du contenu du log de la TempDB n'a fait que grossir du 03/05/11 au 12/05/11.
Y a-t-il un moyen pour savoir quels sont la ou les requêtes en cours qui utilisent la TempDB ?

Cordialement.

Voyez la requête suivante et regardez la colonne DB.

Voyez ici et ici comment voir s'il existe des tables temporaires, et comment lister leurs colonnes.

@++ ;)

Attention également à certaines tâches de maintenance qui peuvent utiliser tempdb de manière intensive comme les reconstructions d'index avec tri dans tempdb et DBCC CHECKDB

++

Citation:

---

Envoyé par mikedavem

Une base tempdb qui peut être fortement utilisé par exemple.
J'ai exactement le même symptôme chez un de mes clients qui utilise beaucoup les objets temporaires, les jointures, les opérations de regroupement et de tri ...

++

---

L'utilisation du niveau d'isolation snapshot, le recours aux trigger, aux clauses OUTPUT, aux curseurs...