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.

++