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 :

Checkpoint en mode de récupération compléte


Sujet :

Administration SQL Server

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre éclairé
    Homme Profil pro
    test
    Inscrit en
    Mai 2016
    Messages
    347
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : Algérie

    Informations professionnelles :
    Activité : test
    Secteur : Boutique - Magasin

    Informations forums :
    Inscription : Mai 2016
    Messages : 347
    Par défaut Checkpoint en mode de récupération compléte
    bonjour a tous
    Une petit Question pour nos experts SQL server
    Si mon Base est en mode de récupération compléte
    et j'ai pas un backup régulier pour purgées du journal à intervalles réguliers et je suis devant un phénomène de saturation du log
    Est ce que la lancement manuel d'opération "checkpoint" peut vider le contenu du log
    ou je doit lancer l'opération recommandé backup log + DBCC SHRINKFILE
    n'hésitez pas à me corriger si je dit des bêtise
    merci pour vos remarques

  2. #2
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par NULL008 Voir le message
    Si mon Base est en mode de récupération compléte
    et j'ai pas un backup régulier pour purgées du journal à intervalles réguliers et je suis devant un phénomène de saturation du log
    Ben pourquoi garder un mode de récupération complet quand on ne fait pas les backups du LOG ? Le problème est plutôt là !
    Changer le mode à SIMPLE à ce moment.
    C'est comme choisir du diesel alors qu'on a une voiture à essence, y a comme un truc qui n'est pas cohérent !

  3. #3
    Membre éclairé
    Homme Profil pro
    test
    Inscrit en
    Mai 2016
    Messages
    347
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : Algérie

    Informations professionnelles :
    Activité : test
    Secteur : Boutique - Magasin

    Informations forums :
    Inscription : Mai 2016
    Messages : 347
    Par défaut
    merci bien pour votre réponse
    vu que je suis débutant et loin d’être expert
    je pause une autre Question su le même piste
    si on parle de saturation du Fichier log
    s'agit'il d'une saturation phyisque (occupation total d'espace disque) ou on parle d'une saturation logique taille du fichier journal occupé a 100%
    merci

  4. #4
    Expert confirmé
    Avatar de mikedavem
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2005
    Messages
    5 450
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Distribution

    Informations forums :
    Inscription : Août 2005
    Messages : 5 450
    Par défaut
    Le journal de transactions sous SQL Server est composé / découpé logiquement de fichiers virtuels (VLF).
    Lorsque ceux-ci se remplissent c'est bien l'espace physique correspond qui est occupé. Un VLF peut être actif ou inactif et dans le dernier cas les données présentes seront écrasées physiquement par d'autres enregistrements.

    Lorsqu'on dit qu'un fichier journal est saturé c'est que tous les VLF qui le composent sont actifs et ne peuvent plus être réutilisés par SQL Server tant qu'un checkpoint / backup log / réplication soit effectué. Dans ce cas tu as plusieurs choix possibles:

    - tu as de la place et l'expansion de fichier est autorisé (autogrow). Dans ce cas SQL Server étendra physiquement le fichier avec de nouveaux VLFs
    - tu n'as plus de place ou l'autogrow n'est pas autorisée et tu auras une erreur stipulant que tu ne peux plus écrire dans le journal des transactions correspond

    ++

  5. #5
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    22 010
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 22 010
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par NULL008 Voir le message
    Est ce que la lancement manuel d'opération "checkpoint" peut vider le contenu du log
    Non ! Absolument pas... Extrait de notre livre
    Nom : Couverture livre SQL server Eyrolles.jpg
Affichages : 164
Taille : 105,0 Ko :


    Écriture des données
    Lors de l’envoi de la commande CHECKPOINT (effectuée automatiquement à intervalle régulier, environ
    toutes les minutes), le système parcourt la mémoire à la recherche des pages sales, qui contiennent
    donc les nouvelles données à écrire. Il les regroupe par contiguïtés des emplacements physiques sur les
    plateaux du disque et les écrit dans les fichiers de données, ceci afin d’optimiser la durée du processus.
    • Si une page mémoire a été modifiée plusieurs fois entre deux commandes CHECKPOINT, une seule écriture
    physique sera effectuée.
    • Le regroupement par contiguïtés des emplacements physiques sur les plateaux du disque permet de
    minimiser le trajet de la tête de lecture.
    Une fois que les pages sales ont été définitivement répercutées dans les fichiers de données, les transactions
    inscrites au journal et concernant ces pages sont marquées comme terminées et la place qu’elles
    occupent dans le journal peut être libérée.


    Peut être libéré ne veut pas dire est libéré...


    ou je doit lancer l'opération recommandé backup log + DBCC SHRINKFILE
    OUI ! Il existe un autre moyen, beaucoup plus dégueulasse (tant qu'a faire de la merde, n'hésitez pas...) qui consiste à passer alternativement du mode de récupération FULL au mode SIMPLE.... et de faire un SHRINK.
    De toute façons dans les deux cas faire un SHRINK est une imbécilité ! C'est une opération d'urgence, pas une opération à planifier !
    n'hésitez pas à me corriger si je dit des bêtise
    merci pour vos remarques
    Dire, non, faire, oui !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

Discussions similaires

  1. Réponses: 2
    Dernier message: 01/08/2014, 12h52
  2. Mode de récupération simple et fichier log
    Par Zabriskir dans le forum Administration
    Réponses: 6
    Dernier message: 29/12/2008, 15h24
  3. Récupération données d'une base en mode texte
    Par bs1705 dans le forum Prolog
    Réponses: 1
    Dernier message: 14/12/2007, 21h54
  4. [XP] Récupération + BSOD même en mode sans échec!
    Par Rodrigue dans le forum Windows XP
    Réponses: 3
    Dernier message: 30/09/2007, 18h04
  5. Récupération du nom de domaine et non de l'url complète
    Par guillaumeIOB dans le forum Langage
    Réponses: 1
    Dernier message: 17/02/2007, 11h35

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