Discussion :

[cboromir]

Bonjour,

Je travaille avec une base de donnée sous SQL SERVER 2000 dont voici les propriétés :
- 40 Go pour les données
- 20 Go pour les index
- 30 Go pour le journal de transaction

Ce journal de transaction est sauvegardé toutes les nuits à 4h00, seulement celui-ci n'est pas purgé je m'explique :
Le matin avant la sauvegarde la taille occupé réellement est de 15Go,
Le matin à 8h celui-ci fait encore 18Go et impossible d'avoir 18Go de log en 4h au vu de l'activité du site et des traitements qui sont effectués sur la base.

Ce que je trouve aussi bizarre c'est que le journal de transaction ne grossis pas indéfiniment, donc il doit y avoir une purge de faite régulièrement sur les transactions obsolètes mais je n'arrive pas à trouver d'information à ce sujet.

La purge du journal de transaction ce fait bien juste après sa sauvegarde logiquement ?


2ème question Pour une autre base de donnée :
- 3 Go pour les données
- 3 Go pour les index
- 9 Go pour le journal de transaction

Du jour au lendemain sans faire de DBCC SHRINKFILE la taille alloué du journal de transaction est passé de 9Go à 3,5Go. Je précise que la taille occupé par les logs du journal n'était que de quelques Mo.

Est ce que vous avez une explication parce que la je sèche complètement?

[elsuket]

Bonjour,

La purge du journal de transaction ce fait bien juste après sa sauvegarde logiquement ?

C'est la cas si votre base de données est en mode de restauration complète.

Du jour au lendemain sans faire de DBCC SHRINKFILE la taille alloué du journal de transaction est passé de 9Go à 3,5Go. Je précise que la taille occupé par les logs du journal n'était que de quelques Mo.

Les fichiers de base de données ne réduisent pas de taille tout seul.
N'y aurait-il pas une tâche de réduction de la base de données (plan de maintenance par exemple ?)

@++

[cboromir]

C'est la cas si votre base de données est en mode de restauration complète.

Ma base de donnée est bien en restauration complète je viens de vérifier
La taille du journal de transaction ne peut pas influer sur sa purge ?

N'y aurait-il pas une tâche de réduction de la base de données (plan de maintenance par exemple ?)

Non c'est une toute nouvelle base je l'ai créer hier et ce matin le journal est passé de 9Go à 3,5Go, la base est aussi en mode restauration complète.
Les seuls plans de maintenance qui sont effectués sur cette base sont la sauvegarde des données et du journal de transaction.

Je suis sur qu'il doit y avoir une explication mais je ne l'explique pas car il n'y a que moi qui ai accès à cette base et je n'ai pas lancé de réduction du fichier en question.

[elsuket]

Bonjour,

La taille du journal de transaction ne peut pas influer sur sa purge ?

Absolument pas.

Je ne vois pas non plus ce qui aurait pu causer une réduction de la taille physique du journal de transactions, les opérations de réduction ne pouvant être programmées que manuellement dans du code ou bien dans un plan de maintenance.
Il reste cependant l'option AUTO_SHRINK (réduction automatique) qui peut être activée.
Vous pouvez le savoir en exécutant la requête suivante :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
SELECT name,
		CASE status
			WHEN 1 THEN 'AUTO_CLOSE'
			WHEN 4 THEN 'SELECT INTO/BULKCOPY'
			WHEN 8 THEN 'CHECKPOINT'
			WHEN 16 THEN 'TORN PAGE DETECTION'
			WHEN 24 THEN 'TRUNC. LOG ON CHKPT + TORN PAGE DETECTION'
			WHEN 28 THEN 'SELECT INTO/BULKCOPY + TRUNC. LOG ON CHKPT + TORN PAGE DETECTION'
			WHEN 32 THEN 'LOADING'
			WHEN 64 THEN 'PRE-RECOVERY'
			WHEN 128 THEN 'RECOVERING'
			WHEN 256 THEN 'NOT RECOVERED'
			WHEN 320 THEN 'NOT RECOVERED + PRE RECOVERY = SUSPECT'
			WHEN 512 THEN 'OFFLINE'
			WHEN 528 THEN 'OFFLINE + TORN PAGE DETECTION'
			WHEN 1024 THEN 'READ_ONLY'
			WHEN 2048 THEN 'dbo USE ONLY'
			WHEN 4096 THEN 'SINGLE_USER'
			WHEN 32768 THEN 'EMERGENCY'
			WHEN 262144 THEN 'MISSING FILES'
			WHEN 4194304 THEN 'AUTO_SHRINK'
			WHEN 4194328 THEN 'AUTO_SHRINK + TRUNC. LOG ON CHKPT + TORN PAGE DETECTION'
			WHEN 16777216 THEN 'AUTO_CREATE_STATISTICS'
			WHEN 1073741824 THEN 'CLEANLY SHUTDOWN'
			WHEN 1090519040 THEN 'AUTO_UPDATE_STATISTICS + AUTO_CREATE_STATISTICS'
			WHEN 1073741840 THEN 'CLEANLY SHUTDOWN + TORN PAGE DETECTION'
		END etat
FROM master.dbo.sysdatabases
WHERE name NOT IN ('master', 'msdb', 'model','distribution', 'ReportServer', 'ReportServerTempDB', 'pubs')

@++

[cboromir]

Pour commencer merci pour tes réponses elsuket.

Je continue de chercher pour l'histoire du journal de transaction qui ne se flush pas.

Pour ce qui est du journal de transaction qui s'est réduit sans prévenir, j'ai exécuté ta requête et celle-ci m'as renvoyé ceci : TORN PAGE DETECTION.
Donc je suppose que cela veut dire qu'elle n'est pas en AUTO-SHRINK.

[elsuket]

Donc je suppose que cela veut dire qu'elle n'est pas en AUTO-SHRINK.

Je confirme

@++