Rendre un fichier de log cyclique

Bonjour,

Dans mon projet, je dois gérer une base de données qui fait un très grand nombre de transactions. Le fichier de log augmente donc avec le temps de manière très importante.
Dans les options , je remarque que mon fichier de log a une taille initiale de 100MB, puis un Autogrowth "By 10MB, restricted growth to 2097152MB".
Cette option veut-elle dire que le fichier est cyclique (je n'en suis pas sure, car nous avons eu l'erreur "fichier de log full") ? Comment faire pour rendre mon fichier de log cyclique ?

Je vous remercie d'avance

Bonjour,

2 choses à regarder :

- J'ai remarqué que vous avez fixé une limite à votre journal (Taille max).
Votre journal des transactions est il bien dimensionné par rapport à l'activité transactionnelle de votre base ?
Vous pouvez également laisser s'étendre votre journal sans fixer de limite et mettre en place une surveillance vous alertant par exemple d'un manque de place ... ce qui vous permet d'avoir une fenêtre de réaction plus longue.

- Quel est le mode de récupération de votre base ?
Si SIMPLE votre journal se videra automatiquement.
Si FULL ou BULK LOGGED avez vous mis en place une stratégie de sauvegarde régulière de votre journal ? Le BACKUP de votre journal vous permet de vider le journal et de le rendre ce que vous qualifiez de "cyclique". Sans cette sauvegarde votre fichier se remplira indéfiniment sans jamais se vider.

++

Pour la limite du journal: dans le fichier de creation de la base, je vois que DB_LOG_SIZE est à 100 MB , puis DB_LOG_FILEGROWTH à 10 MB. Je pense que le restricted growth à 2G est donc la taille maximale par défaut dans sql server. Quand cette taille est atteinte, que se passe-t-il ? le fichier part en erreur ?

Pour le mode de recuperation de la base de donnee : est-il possible de recuperer cette information depuis l'IHM de sql server 2005 ?

(desolee, je suis tres tres newbie....)

En fouillant un peu, j'ai trouvé un "Recovery Model" à Simple. Mais je ne sais pas si ca concernait le fichier de log.
Si je vous suis, ca voudrais dire que mon fichier de log est censé être (déjà) cyclique ?

Citation:

---

Envoyé par miniloutre

Pour la limite du journal: dans le fichier de creation de la base, je vois que DB_LOG_SIZE est à 100 MB , puis DB_LOG_FILEGROWTH à 10 MB. Je pense que le restricted growth à 2G est donc la taille maximale par défaut dans sql server. Quand cette taille est atteinte, que se passe-t-il ? le fichier part en erreur ?

Pour le mode de recuperation de la base de donnee : est-il possible de recuperer cette information depuis l'IHM de sql server 2005 ?

(desolee, je suis tres tres newbie....)

---

Pas de souci

Effectivement les 2G sont la limite max de votre journal.
Si celui-ci atteint cette limite max, vous aurez un message d'erreur de fichier journal plein et ne pourrez plus mettre à jour vos données.
Si ce problème se produit en mode de récupération SIMPLE et sans rentrer dans le détail c'est que vous avez certainement un gros volume d'activité transactionnel qui doit s'opérer. Le journal ne se videra qu'après la fin d'une transaction validée. Dimensionnez correctement votre journal en conséquence pour que ce problème n'arrive plus.

Si vous êtes en mode FULL ou BULK LOGGED vous devrez faire faire une sauvegarde de votre journal pour que celui-ci se vide.

Depuis l'IHM il est possible de visualiser le mode de récupération en faisant un clic droit sur la base concernée et propriétés. Dans la partie option il me semble vous trouverez cette information.

++

Merci

En effet, je suis bien en "simple". Par contre, la taille max du fichier à l'air d'être limitée à 10GB par sql server, et ma requête (qui est une requête de purge) fait dans les 30GB de log... Je suppose donc qu'il va falloir que je "saucissonne" ma purge en petits morceaux.
La première solution que je vois, c'est de faire plusieurs delete sur un nb donné d'enregistrement, et faire un dernier delete sur tous ceux qui restent.
L'autre solution, ce serait de faire des delete qui aurait pour paramètre un temps maximal d'exécution de la requête, puis faire un dernier delete sur tous ceux qui restent aussi.
Intuitivement, je trouve que la deuxième solution serait meilleure, car je ne sais pas bien combien d'enregistrements sont à supprimer à chaque fois, et de plus leur taille varie bcp de l'un à l'autre (je fais des delete one cascade). Mais pour l'instant je ne vois pas du tout comment l'implémenter.
Si qqun à des idées ou des conseils, je suis preneuse : )

Merci merci

Une autre solution et plus simple je trouve est d'augmenter la taille max de votre journal des transactions en conséquence en vous laissant bien sûr une marge de sécurité.

++

Je ne peux pas augmenter sa taille suffisamment, car ce journal se situe sur une partition de 10GB sur le système de production, cette partition ne peut pas être changée.

Dans ce cas avez vous une autre partition ou vous pourriez ajouter un fichier journal ?

Si tel est le cas, cela résoudra votre problème de taille de journal des transactions

++

Bonjour,

Pour information sur l'utilisation cyclique du fichier de journal des transactions, on peut utiliser la commande DBCC LOGINFO(maBase) qui permet de connaître le nombre de journaux de transaction virtuels total.
Lorsque la colonne status est valuée à 2, c'est que ce journal de transaction virtuel est en cours d'utilisation, sinon elle valuée à 0.

@++ ;)

Merci à tous,

en fait, je ne peux pas déplacer ce fichier ailleurs, car ce sont des ordinateurs déjà en production, on ne peut modifier les partitions, ni choisir un autre emplacement.

Par contre, j'ai "splitté" la requete de delete en petits morceaux dans une boucle while, ca ne prend pas plus de temps que la requete qui enlevait tout d'un coup et ca a l'air de fonctionner : )