IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Administration SQL Server Discussion :

Utilité backup Log 2k


Sujet :

Administration SQL Server

  1. #1
    Membre confirmé
    Inscrit en
    Mai 2006
    Messages
    161
    Détails du profil
    Informations forums :
    Inscription : Mai 2006
    Messages : 161
    Par défaut Utilité backup Log 2k
    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.

  2. #2
    Membre Expert
    Avatar de rudib
    Homme Profil pro
    Fakir SQL Server & NoSQL
    Inscrit en
    Mai 2006
    Messages
    2 573
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Fakir SQL Server & NoSQL

    Informations forums :
    Inscription : Mai 2006
    Messages : 2 573
    Par défaut
    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)

  3. #3
    Membre expérimenté
    Inscrit en
    Octobre 2005
    Messages
    344
    Détails du profil
    Informations forums :
    Inscription : Octobre 2005
    Messages : 344
    Par défaut
    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.

  4. #4
    Membre confirmé
    Inscrit en
    Mai 2006
    Messages
    161
    Détails du profil
    Informations forums :
    Inscription : Mai 2006
    Messages : 161
    Par défaut
    Citation Envoyé par 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.
    merci pour la réponse
    est ce que "vider le journal" remet sa taille à sa valeur initiale ?

  5. #5
    Membre confirmé
    Inscrit en
    Mai 2006
    Messages
    161
    Détails du profil
    Informations forums :
    Inscription : Mai 2006
    Messages : 161
    Par défaut
    Citation Envoyé par 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)
    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

  6. #6
    Membre Expert
    Avatar de rudib
    Homme Profil pro
    Fakir SQL Server & NoSQL
    Inscrit en
    Mai 2006
    Messages
    2 573
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Fakir SQL Server & NoSQL

    Informations forums :
    Inscription : Mai 2006
    Messages : 2 573
    Par défaut
    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.

  7. #7
    Membre expérimenté
    Inscrit en
    Octobre 2005
    Messages
    344
    Détails du profil
    Informations forums :
    Inscription : Octobre 2005
    Messages : 344
    Par défaut
    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.

Discussions similaires

  1. [2005] Downgrading backup log buffers from 1024K to 64K
    Par nmathon dans le forum Administration
    Réponses: 3
    Dernier message: 08/03/2013, 09h30
  2. [2008R2] backup Differentiel et backup Log
    Par scazikiss dans le forum Administration
    Réponses: 2
    Dernier message: 19/02/2013, 23h09
  3. [MSSQL Serveur 2008] Erreur lors d'un BACKUP LOG
    Par J0r_x dans le forum Administration
    Réponses: 14
    Dernier message: 07/04/2012, 10h11
  4. [SQLEXPRESS2005] Probleme BACKUP LOG
    Par abrial dans le forum Administration
    Réponses: 2
    Dernier message: 22/02/2008, 14h19
  5. [sql Server Express 2005]backup Log
    Par abrial dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 23/06/2006, 15h20

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo