Discussion :

[6bil1]

Bonjour,

j'ai un probleme avec mon journal de transaction. Il est énorme.

Agr_log.ldf fait 250 Go (Journal de transaction)
Agr_Data.mdf fait 155 Go (Les données)

Tous les soirs, je fais une sauvegarde de la base et du journal de transaction.
La base est en mode de récuperation complet


En cherchant sur le net, j'ai trouvé des commandes ->

Voici les commandes que j'ai passé :

CHECKPOINT
BACKUP LOG agresso WITH TRUNCATE_ONLY
BACKUP TRANSACTION agresso WITH NO_LOG

USE Agresso
GO
DBCC SHRINKFILE ('agrLog')
GO

(La commande se passe bien)

ou encore

USE Agresso
GO
DBCC SHRINKFILE ('agrLog', 200)
GO

(La commande se passe bien aussi) Il me sort :
7 2 26522560 128 26522560 128





Dans un plan de maintenance, j'ai fait reduire la base, mais rien.Ca ne veut pas se réduire.

je souhaite passer le journal à 200 mo.

[elsuket]

Bonjour,

C'est une erreur que de vouloir réduire la taille d'une base de données.
En effet, lorsque SQL Server décide d'augmenter la taille d'un fichier, il doit effectuer un nombre importants d'accès disque. Cela crée une contention importante au niveau des transaction, puisque comme vous vous en doutez, les accès disques sont au moins 1000 fois plus lents qu'un accès en RAM.

Lorsque vous réduisez une base de données, vous supprimez les pages que SQL Server s'est échiné à allouer sur le disque, et qu'il devra ré-allouer tôt ou tard, donc vous créez vous-même de la contention

C'est pourquoi la manœuvre de réduction de la base de données ne doit être réservée qu'aux cas d'urgence, du style manque d'espace disque.

Enfin, un grossissement des fichiers de base de données indique souvent une mauvaise estimation du dimensionnement des données.
A l'allocation des pages, vous créez de la fragmentation dans vos fichiers, je vous laisse imaginer les conséquences que cela a sur les performances globales de votre base de données
Taillez donc vos fichiers de sorte qu'ils n'aient pas ou peu à grossir, en estimant la taille des données à stocker sur 3 ans ou un peu plus

La troncature du fichier du journal des transactions ne conduit donc pas à une réduction de la taille de celui-ci, mais seulement à un "nettoyage" journaux virtuels qui sont contenus dans le fichier de journal des transactions de votre BD.

Regardez la colonne log_reuse_wait_desc de la table système sys.databases pour votre base de données, et dites-nous quelle valeurs elle prend

Si vous souhaitez que votre fichier de journal des transaction ne grossisse pas, taillez le correctement et effectuez des sauvegardes de celui-ci de façon plus fréquente.

Enfin, le mode de restauration d'une base de données est à choisir avec précaution, suivant la quantité de données que vous pouvez vous "permettre" de perdre en cas de crash. Dans votre cas, est-il acceptable de perdre une journée de données ? Si ce n'est pas le cas, cela vous fait une raison supplémentaire pour effectuer des sauvegardes du journal des transaction plus fréquemment

Votre base de données est-elle OLTP ou accédée seulement en lecture seule ?

@++

[6bil1]

Voici le résultat de la commande SELECT log_reuse_wait_desc FROM sys.DATABASES :

NOTHING
NOTHING
NOTHING
NOTHING
NOTHING
NOTHING
ACTIVE_TRANSACTION

La base est OLTP. C'est une application metier qui "dirige" cette base.

j'ai contacté le fournisseur et en effet, il em confirme que 250 Go de journal de transaction c'est énorme. Il conseil 200 Mo

De plus, je commence à avoir un problème de place sur mon serveur...

[SQLpro]

j'ai contacté le fournisseur et en effet, il em confirme que 250 Go de journal de transaction c'est énorme. Il conseil 200 Mo

C'est un conseil hautement stupide d'un fournisseur qui ne maîtrise vraiment pas l'administration de bases de données.

Comme on vous l'as dit, réduire à si peu un journal de transaction est d'une parfaite stupidité. Lisez l'article que j'ai écrit à ce sujet :
1) http://blog.developpez.com/sqlpro/p5...fichiers-et-t/
en particulier paragraphe intitulé "Pire ! C'est possible..."
2) http://sqlpro.developpez.com/cours/sqlserver/log/
en cas d'urgence, comment réduire le JT

Cependant sachez qu'un JT ne peut se réduire à moins de sa taille de départ...

A +

[6bil1]

Justement, je me suis basé sur votre article pour essayer de réduire le journal mais ca n'a rien fait !
J'ai bien suivi votre article, c'est pour ca qu'au début, j'ai posté les commandes que j'ai passé.

[6bil1]

Si je passe la commande

DBCC SQLPERD (LOGSPACE)
j'ai ce résultat :

Databasename Log Size MB Log Space Used statut
Agresso 233626,3 98,43719 0



Donc, je lance la commande BACKUP LOG Agresso WITH TRUNCATE_ONLY

et ensuite dbcc shrinkfile (AgrLog)

Et j'ai le meme résultat ! On dirait qu'il ne vide pas le journal... Il grossit