Discussion :

[lastsql]

Bonjour tous le monde.

Voila je débute dans le monde sql
Mon prédecesseur a mis en place un plan de maintenance afin d'une part sauvegarder la base et de reduire la taille du fichier log
Hors ça copie bien la sauvegarde mais mon disque est saturé car le log ne se réduit pas !

Pour synthétiser le tout
J'ai le

Code :

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

1
2
3
4
5
6
-->back Up database task
-->Exexute T-sql statement task
use ows
BACKUP LOG OWS with truncate_only
DBCC SHRINKFILE(OWS_log, 10)
--> Shrink database task

Alors bon j'ai essayer de mettre dans une requete le DBCC SHRINKFILE(OWS_log, 10) mais ça m'a mis une erreur comme quoi il ne trouve pas le fichier log ... est ce que je suis sur la bonne piste ou pas du tout ??
Merci grandement pour votre aide

[kagemaru]

bonjour

Référez-vous à ce tutoriel, vous devriez trouver votre bonheur :

http://sqlpro.developpez.com/cours/sqlserver/log/

ps : ce post devrait être dans la partie Admin.

[elsuket]

Bonjour,

et de reduire la taille du fichier log

A ne jamais faire sauf en cas d'urgence comme SQLPro le dit dans son article.
Si le fichier du journal des transactions grossit trop, c'est soit parce que votre manager est radin, soit parce que vous ne faites pas assez souvent de sauvegardes du fichier du journal des transactions.

Toute transaction (c'est à dire tout SELECT, INSERT, UPDATE, DELETE, et d'autres opérations) est journalisée dans le fichier du journal des transaction pour garantir l'ACIDité de la base de données.
Donc avant même de modifier les données dans le fichier de données, le moteur enregistre la modification de données d'abord dans ce fichier.
Ce qui fait que si votre fichier de journal n'est pas assez gros pour stocker les données manipulées par une transaction, la transaction va attendre que le fichier du journal des transactions ait fini de grossir pour les y inscrire.
Tôt ou tard donc, votre fichier du journal des transaction grossira de nouveau, il ne peut pas en aller autrement.
Cela conduit bien sûr à la fragmentation de ce fichier ...

Autant dire que la personne qui a créé ce plan de maintenance s'est peu soucié de l'impact que cela peut avoir sur les performances globales de la base de données, quand on connait la vitesse d'écriture sur disque ...

Ce que vous avez donc de mieux à faire est de savoir combien de temps de données vous pouvez vous permettre de perdre, et programmer des sauvegardes du fichier du journal des transaction en conséquence.
Par exemple si nous travaillons dans un hôpital où on estime que l'on peut perdre une minute de données, on va programmer la sauvegarde du fichier du journal des transactions toutes les minutes.
De cette façon nous sommes à peu près certains de ne perdre que très peu de données, et que la taille du fichier du journal des transactions conservera à peu près toujours la même taille.

Mais il se peut également qu'une transaction longue et/ou qui est restée ouverte bloque la troncature du journal.
Si vous êtes sous SQL Server 2005 ou plus, cela vous est indiqué par la colonne log_reuse_wait_desc de la vue système sys.databases

@++