Discussion :

[Arnard]

Bonjour,

je souhaite gérer les journaux de logs de manière automatique. Une base de données d'historiques est nourri par d'autres serveurs, et j'ai paramétré cette base pour que le journal n'excède pas X Go.

Comme il s'agit d'un jeu de données secondaire, la sauvegarde se fait à l'année, mais la base n'a une durée de vie que d'un an (soit Histo2010, Histo2011, ...).

J'ai vu cette discussion : http://www.developpez.net/forums/d30...e-fichier-ldf/

mais cela ne parle que de gestion manuelle.

Dans Management Studio, sur une base de données, dans Propriétés/Options/Réduction automatique, cette propriété peut-elle jouer sur le traitement ?

Merci pour vos lumières

[Ptit_Dje]

Bonjour,

Dans quel mode de recovery se trouve votre base ?
Si elle est en full, avez vous un job de sauvegarde du journal de transaction ?

Lorsque vous dites:

La sauvegarde se fait à l'année

Est ce que ca signifie que vous effectuer un backup de votre base sur une fréquence annuelle ?!

Comment votre base de données est elle alimentée ?

Bonne journée

[Arnard]

Je n'ai pas touché à ce point de configuration, il me semble qu'elle est en simple (je vais quand même vérifier ça, au pire changer de mode de récupération est une opération couteuse ?).

Oui, il s'agit du backup (un seul) à fréquence annuelle (au 31 décembre de l'année correspondant à la base de données), réalisé par un outil tiers made in HP.

La base est alimentée par procédure stockée exécutée de manière chronique, procédure situées sur d'autres serveurs, ayant pour but de migrer les données vers cette table située sur ce serveur (on centralise donc).

J'ai vu l'option d'auto-shrink disponible dans Management Studio, mais sur Internet il est recommandé de ne pas l'utiliser... Donc je m'en remets aux experts

Merci !

[elsuket]

Bonjour,

Pour connaître le mode de récupération de votre base de données, si vous êtes sous SQL Server 2005 ou 2008, vous pouvez exécuter :

Code :

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

1
2
3
SELECT name, recovery_model_desc
FROM sys.databases
WHERE name = 'maBD'

Et sur toutes les versions, au moins depuis la 2000 :

Code :

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

SELECT DATABASEPROPERTYEX('maBD','Recovery')

Ne pas sauvegarder sa base de données régulièrement est très dangereux ... que ferez-vous si le(s) disque(s) qui la supportent connaissent une panne ?
De même ne pas tester ses backups de temps en temps est un jeu dangereux ...

Changer de mode de restauration n'est pas coûteux, mais n'est pas sans conséquences.

- FULL : vous pouvez vous permettre de perdre un minimum de données, et cela vous est permis par une sauvegarde régulière du fichier du journal des transactions.
Mais en aucun cas cela ne réduit la taille du fichier du journal des transactions : SQL Server ne restitue jamais l'espace (RAM ou disque) qu'il s'est échiné à s'octroyer.

- SIMPLE : le fichier du journal grossit suivant le volume de données que les transactions manipulent, mais il est tronqué (<> réduit) lors de la validation de toute transaction.
Ceci fait que si une panne se produit, vous perdrez toutes les modifications de données effectuées depuis la dernière sauvegarde de la base de données.

- BULK_LOGGED fonctionne suivant le même schéma que le mode FULL, mais il journalise de façon minimale les opérations en bloc (BULK INSERT, ...), ce qui permet d'obtenir un gain de performances important sur les imports de données.

Ne fixez jamais la taille de votre fichier du journal des transactions, quel que soit le mode de récupération. Utilisez pour cela une taille de croissance de votre fichier en MB (pas un pourcentage).
Taillez-le suivant la taille de votre fichier de données, on conseille environ 30%.
En effet si le volume de données manipulé par les transaction dépasse la taille fixée, alors la transaction est annulée.

Gardez à l'esprit qu'une réduction de fichier de base de données ne doit s'utiliser qu'en cas d'urgence : manque d'espace disque.
Dans les autres cas, c'est le meilleur moyen de faire baisser les performances de votre base de données.

@++

[Arnard]

Je me suis trompé, la base est en mode Complet. Apparemment le mode Complet génère beaucoup d'enregistrements dans le journal de logs non libérés par défaut... Si je comprends bien, j'ai plusieurs options :

- Passer en mode simple, ce qui signifie que le journal ne devrait croitre que le temps d'une transaction et décroitre à la fin de celle-ci ? Si plusieurs transactions s'enchainent (8 en 1 mn), cela ne pose pas de souci ?

- Laisser en complet, mais dans ce cas là quelle action permet de libérer de la place dans le journal de logs ? Une action de sauvegarde ? une commande SHRINK ? Je rappelle rechercher une solution automatique.

Ne fixez jamais la taille de votre fichier du journal des transactions, quel que soit le mode de récupération. Utilisez pour cela une taille de croissance de votre fichier en MB (pas un pourcentage).

Aïe, moi qui avais fixé à 15Go (Histoire d'éviter que d'ici quelques temps je me retoruve avec 0Mo d'espace libre sur ce serveur) au lieu des 2To par défaut (croissance pourcentage aussi par défaut)... La configuration par défaut d'une base de données SQL Server 2005 semble pas top à te lire...

Au sujet de la base de données, il s'agit d'une base miroir représentant les informations d'une année, j'ai les données dans une autre base qui elle est sauvegardée de manière régulière... Donc le fait que la sauvegarde ne soit faite qu'à la fin ne me dérange pas (voir ça comme une archive).

[mikedavem]

Posez vous la questions suivante :

- Si je perds les données de la base au cours de l'année est ce que celle-ci doit pouvoir être restaurée en l'état juste avant un éventuel crash ?

Si la réponse est oui alors vous allez devoir utiliser le mode de récupération complet et adopter une stratégie de sauvegarde en conséquence.

La encore il faudra se poser une autre question :

- De quel délai je dispose pour restaurer ma base ?

Selon le cas vous allez devoir adapter votre stratégie de sauvegarde (Par exemple sauvegarde complète + différentielle + journaux à planifier par exemple).


Si la réponse est négative alors vous pourrez utiliser le mode simple qui supprimera toute intervention supplémentaire sur les journaux.

++

[Arnard]

Je n'ai pas un besoin de récupération des données immédiat, donc si je suis le raisonnement, un fonctionnement SIMPLE me suffit et permettra une gestion automatique de ce fichier journal...

Dernière question, durant mes recherches, j'ai trouvé cette requête

Code :

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

exec sp_dboption(VotreBase, 'trunc log', true)

sur ce post : http://www.developpez.net/forums/d18...-transactions/

Cette dernière approche se fait-elle dans une approche Complete et si oui est-elle suffisante pour la gestion automatique des logs ?

Merci

[mikedavem]

Non cette option n'est pas adaptée pour une stratégie de sauvegarde utilisant le mode complet car elle tronque automatiquement la partie inactive du journal à chaque checkpoint (environ toutes les minutes) ce qui est en contradiction avec une politique de sauvegarde des journaux.

Vous pouvez l'utiliser avec le mode de récupération SIMPLE cependant mais à voir si cela est vraiment nécessaire dans votre cas.

++

[Arnard]

Merci à tous, c'est déjà plus clair

Je vais passer la bdD en mode Simple et voir ce que ça donne.

Bye !
--
Edit : je rajoute une question par curiosité. Dans le cadre d'un fonctionnement en Complet, quelle opération assure une diminution de la taille du journal ? Une sauvegarde du fichier de log ? De la base de données ? Des deux ? Autre ?

[Ptit_Dje]

La sauvegarde du fichier log, qui peut très bien être automatisée.
Enfin, ce n'est pas une réduction de la taille physique du fichier, ca "vide" son contenu, et l'espace peut être réutiliser pour enregistrer d'autres transactions.
Ce qui permet de garder un fichier de taille plus ou moins constante.

[elsuket]

Le mode de récupération SIMPLE ne vous exempte pas d'une sauvegarde régulière (tous les jours ?)

[Arnard]

Comme indiqué précédemment cette base n'est qu'une archive d'une autre base, la sauvegarde journalière n'est pas pas requise pour cette base.

Pour la réduction, on se comprend bien, du moment qu'il exploite l'espace à sa disposition de manière cyclique !

Merci pour ces infos

[Ptit_Dje]

Comme indiqué précédemment cette base n'est qu'une archive d'une autre base, la sauvegarde journalière n'est pas pas requise pour cette base.

Pourquoi ne pas vous en débarasser et archiver la base principale à la fin de chaque année dans ce cas ?

[Arnard]

La base principale est archivée tous les jours (avec la conf et tout, pas envie de perdre pour un an de taff xD), par contre la base principale recense des informations d'historiques, purgées de manière régulière pour ne garder que X derniers mois (afin d'éviter la surcharge d'historiques), le reste étant mis en place dans ces bases d'archives, bases pour lequelles je suis venu vous consulter sur la gestion du fichier de logs