Logs TempDB ne font que grossir [Résolu]

[mb10]

Bonjour,

Sur une instance SQL Server, j'ai les logs de la TempDB qui ne font que grossir alors que le mode de récupération de cette base est en simple.
Par contre quand les services SQL sont redémarrés, les logs sont bien réinitialisés.

Cordialement.

[iberserk]

Sur une instance SQL Server, j'ai les logs de la TempDB qui ne font que grossir alors que le mode de récupération de cette base est en simple.

Cela ne supprime pas l'utilisation du journal!!! heureusement!
cela ne fait que minimiser ses entrées.

[mb10]

Pourtant comme la base Tempdb est en récupération simple, toutes les transactions terminées doivent automatiquement être supprimées.
Est-ce bien ça ?
Merci de votre réponse.

Cordialement.

[dbaffaleuf]

Il faut vérifier s'il n'y a pas de transactions ouvertes dans tempdb en utilisant des vues comme sys.dm_tran_database_transactions / sys.dm_tran_session_transactions ou dbcc opentran(tempdb):

Code :

1
2
3
4
5
SELECT T.session_id, D.database_transaction_begin_time, D.database_transaction_state, 
D.database_transaction_log_record_count, D.database_transaction_log_bytes_used
, D.database_transaction_begin_lsn, D.database_transaction_last_lsn FROM sys.dm_tran_database_transactions D
INNER JOIN sys.dm_tran_session_transactions T ON T.transaction_id = D.transaction_id 
WHERE database_transaction_begin_time IS NOT NULL AND database_id=2

La valeur à surveiller est database_transaction_state:

1 = The transaction has not been initialized.
3 = The transaction has been initialized but has not generated any log records.
4 = The transaction has generated log records.
5 = The transaction has been prepared.
10 = The transaction has been committed.
11 = The transaction has been rolled back.
12 = The transaction is being committed. In this state the log record is being generated, but it has not been materialized or persisted.

Si la transaction est ouverte, database_transaction_state est à 4. database_transaction_log_bytes_used donne l'espace utilisé dans le journal pour cette transaction.

[mikedavem]

Tout comme dbaffaleuf je pense qu'une transaction est ouverte et empêche le journal de se vider.

++

[mb10]

J'ai lancé la requête sur la base tempdb mais je n'ai aucune ligne de retournée.

Cordialement.

[mikedavem]

Que donne la requête :

Code :

DBCC OPENTRAN

Que retourne la requête

Code :

DBCC SQLPERF(LOGSPACE)

++

[mb10]

DBCC OPENTRAN ne trouve aucune transaction

DBCC SQLPERF(LOGSPACE) donne le résultat suivant :
Database Name | Log Size (MB) | Log Space Used (%) | Status
tempdb | 39999,99 | 64,41029 | 0

le "log space used (%)" ne fait qu'augmenter. Ce n'est qu'après redémarrage des services sql que cette valeur rechute.

Cordialement.

[dbaffaleuf]

-> DBCC OPENTRAN(tempdb)

sans option il cherche dans la base courante. Dans quelle version de SQL Server es-tu ?

[mb10]

DBCC OPENTRAN(tempdb) ne ramène aucun résultat

La version de SQL Server est SQL Server 2008 Entreprise SP1

Cordialement.

[dbaffaleuf]

Est-ce que tu peux nous mettre dans un fichier attaché le résultat d'un :

Code :

1
2
3
4
USE tempdb
GO
SELECT top 4000 * FROM fn_dblog(NULL, NULL)
GO

qu'on voit ce qu'il y a dans ce journal

merci,

[mb10]

Je n'ai pu mettre que les 1430 premières lignes.

Cordialement.

[dbaffaleuf]

OK les transactions sont toutes validées ce qui explique pourquoi les requêtes précédentes ne renvoient rien. Que renvoie par contre:

Code :

SELECT name, log_reuse_wait_desc FROM sys.DATABASES WHERE database_id=2

merci,

[mb10]

La requête renvoie le résultat suivant :

name | log_reuse_wait_desc
tempdb | NOTHING

Cordialement.

[SQLpro]

Envoyé par mb10

Bonjour,

Sur une instance SQL Server, j'ai les logs de la TempDB qui ne font que grossir alors que le mode de récupération de cette base est en simple.
Par contre quand les services SQL sont redémarrés, les logs sont bien réinitialisés.

Cordialement.

Normal qu'ils soient réinitialises car la base tempdb est supprimée et reconstruite à l'identique à chaque démarrage du serveur avec les paramètres initiaux

Mais comment voyez vous (par quelle requête, IHM, mesure) que les logs ont grossit ???

A +

[elsuket]

Bonjour,

- Faites-vous une utilisation massive des tables temporaires ?
- Utilisez vous le niveau d'isolation de transaction SNAPSHOT ?

@++

[mb10]

Réponse à la question de SQLPro :
je lance la requête DBCC SQLPERF(LOGSPACE) tous les jours. Depuis le redémarrage des services SQL (le 05/04/11), le champ Log space used (%) ne fait qu'augmenter.
Ce matin en lançant la requête, ce champ était à 65 %.

Réponse à la question d'Elsuket :
Je ne sais pas comment vérifier ça.

Cordialement.

[elsuket]

Pour les tables temporaires, comme elles sont persistées dans TempDB, on peut exécuter :

Code :

1
2
3
4
USE TempDB
GO
SELECT	COUNT(*)
FROM	sys.TABLES

Vous pouvez aussi chercher dans le code des modules SQL (sys.sql_module) s'il existe des variables de type TABLE (DECLARE @maTable TABLE) ou des tables temporaires (CREATE TABLE (#)#maTable).

Pour le niveau d'isolation de transaction snapshot, que vous retourne la requête suivante ?

Code :

1
2
3
4
5
6
7
8
9
10
SELECT	name
	, is_read_committed_snapshot_on
	, snapshot_isolation_state_desc
FROM	sys.DATABASES
WHERE	(
		is_read_committed_snapshot_on = 1
		OR snapshot_isolation_state_desc = 'ON'
	)
AND	source_database_id IS NULL
AND	name NOT IN ('master', 'msdb')

Savez-vous si des transactions sont exécutées sous le niveau d'isolation de transaction SERIALIZABLE ?

@++

[SQLpro]

Envoyé par mb10

Réponse à la question de SQLPro :
je lance la requête DBCC SQLPERF(LOGSPACE) tous les jours. Depuis le redémarrage des services SQL (le 05/04/11), le champ Log space used (%) ne fait qu'augmenter.
Ce matin en lançant la requête, ce champ était à 65 %..

un pourcentage n'est pas un volume.... 65% signifie que votre fichier qui fait par exemple 10 Mo est utilisé à 65% soit 6.5 Mo. Votre fichier reste donc toujours à la même taille.

A +

[elsuket]

Envoyé par mb10

DBCC SQLPERF(LOGSPACE) donne le résultat suivant :
Database Name | Log Size (MB) | Log Space Used (%) | Status
tempdb | 39999,99 | 64,41029 | 0

Son fichier du journal des transactions de TempDB approche donc les 40GB, et au moment où il a exécuté la requête, presque 26GB étaient occupés

@++