Discussion :

[Bba_M]

Bonjour.
quelle est l'utilité de faire la souvgarde de fichier de journalisation LOG!!.
dans quel cas on aurrai besoin d'utiliser ces fichiers(LOG).
je veux tester des cas d'utilisation pour voir vraiment l'utilité de la sauvgarde LOG. par exemple est ce que je peux restorer une base deja supprimé à partir seulement de son fichier Log deja sauvgardé. dans le cas contraire je vois aucune utilité(pour l'instant )
le "backup" pour les bases est claire pour moi.

d'avance merci.

[rudib]

Bonjour,

Je ne sais pas dans quel environnement tu travailles, ni quelle est ta fréquence de backup complets/différentiels, mais dans un environnement de production, avec des bases dans lesquelles les utilisateurs entrent et modifient des données, c'est assez clair. Pour simplifier :

- fréquence de backups très rapide
- récupération de l'état d'une base à un instant T

En d'autres termes, cela te permet de faire des récupérations sur erreur, et d'inclure dans ton backup des données très fraîches, pour éviter les pertes de modifications depuis ton dernier backup de base.

Le désavantage est le temps de restauration si le nombre de backups de logs est important (il faut tous les appliquer).

Tu ne peux pas restaurer une base seulement avec ses backups de logs. Il te faut au moins un backup complet (+ dernier différentiel si existant)

[usf70]

Une autre utilité de la sauvegarde des LOGs, au cas où le mode de récupération de ta base est en mode "complet" :
C'est le seul moyen de vider le journal des transactions. Si tu ne le fais pas, celui-ci va "grossir" indéfiniment.

[Bba_M]

Une autre utilité de la sauvegarde des LOGs, au cas où le mode de récupération de ta base est en mode "complet" :
C'est le seul moyen de vider le journal des transactions. Si tu ne le fais pas, celui-ci va "grossir" indéfiniment.

merci pour la réponse
est ce que "vider le journal" remet sa taille à sa valeur initiale ?

[Bba_M]

Bonjour,

Je ne sais pas dans quel environnement tu travailles, ni quelle est ta fréquence de backup complets/différentiels, mais dans un environnement de production, avec des bases dans lesquelles les utilisateurs entrent et modifient des données, c'est assez clair. Pour simplifier :

- fréquence de backups très rapide
- récupération de l'état d'une base à un instant T

En d'autres termes, cela te permet de faire des récupérations sur erreur, et d'inclure dans ton backup des données très fraîches, pour éviter les pertes de modifications depuis ton dernier backup de base.

Le désavantage est le temps de restauration si le nombre de backups de logs est important (il faut tous les appliquer).

Tu ne peux pas restaurer une base seulement avec ses backups de logs. Il te faut au moins un backup complet (+ dernier différentiel si existant)

Bonjour, merci pour les réponse.
je travaille sous sql server 2000.
fréquence de backup complet: 1 backup complet chaque semaine.
si par exemple une érreur se produite au melieu de la semaine . comment je peux récupérer de l'état d'une base pour éviter les pertes de modifications depuis mon dernier backup de base.? que je dois faire?
d'avance merci

[rudib]

En général la solution passe par une stratégie utilisant les trois types de backup, pour équilibrer la capacité de récupération et le temps de restauration.

Tu as des infos ici :
http://fadace.developpez.com/mssql/sauve/
http://www.itpro.fr/article.asp?mag=...14&p=1&id=1386

Pour toi, ça pourrait être :
- backup complet hebdo
- différentiel quotidien
- log toutes les heures

cela te permettrait de restaurer avec un perte de données ne dépassant pas une heure.

[usf70]

merci pour la réponse
est ce que "vider le journal" remet sa taille à sa valeur initiale ?

Pour ce qui est de la taille des fichiers de journalisation, en le sauvegardant, il ne fait que supprimer les entrées commitées. Si par malheur, la taille du fichier a augmenté juste avant la sauvegarde, il ne sera pas réduit, c'est juste le taux de remplissage de la log qui sera réduit (que l'on peut vérifier avec dbcc SQLPERF (LOGSPACE) ). La seule façon de réduire la taille du fichier serait un DBCC SHRINKFILE.