none
Shrink Log File RRS feed

 > 

  • Question

  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour

    Je viens vers vous car je rencontre un phénomène bizarre, c'est plus dans un soucis de compréhension que de besoin professionnel.

    J’exécute la commande suivante : 

    ALTER DATABASE [MaBase] SET RECOVERY SIMPLE WITH NO_WAIT
SELECT size / 128 FROM sys.master_files WHERE name = 'MonFicherLog'
DBCC SHRINKFILE (N'MonFicherLog',0) WITH NO_INFOMSGS
SELECT size / 128 FROM sys.master_files WHERE name = 'MonFicherLog'

    Le 1er jeu de résultat me retourne : 68 et le second pareil, preuve que le shrink n'a rien fait.

    Alors que l'instruction suivante montre bien la présence d'un volume inutilisé :

    USE [MaBase]
SELECT size / 128 AS Reserved_MB
, FILEPROPERTY(name, 'SpaceUsed') / 128.0 AS Used_MB
FROM sys.database_files AS dbf WITH(NOLOCK)
WHERE name = 'MonFicherLog'

    Retourne : 68 / 0.54

    Donc je m'attends à ce que la commande suivante : 

    DBCC SHRINKFILE (N'MonFicherLog',0) WITH NO_INFOMSGS

    me diminue la taille du fichier à 1Mb (car c'est la configuration du fichier de log de ma base model).

    Et quand je joue l'instruction suivante :

    ALTER DATABASE [MaBase] SET RECOVERY SIMPLE WITH NO_WAIT
SELECT size / 128 FROM sys.master_files WHERE name = 'MonFicherLog'
DBCC SHRINKFILE (N'MonFicherLog',1) WITH NO_INFOMSGS
SELECT size / 128 FROM sys.master_files WHERE name = 'MonFicherLog'

    Le 1er résultat : 68, le second résultat : 19, pourquoi 19, je ne comprend pas.

    Pourquoi, ces résultats ?

    lundi 2 septembre 2013 13:25
    |

Réponses

Toutes les réponses

  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Après quelques recherches, je suis tombé sur un lien de mikedavem

    Malheureusement, ça ne répond pas à mon interrogation au vu du résultat ci-dessous. Le seul fichier utilisé (status = 2) est le premier.

    lundi 2 septembre 2013 20:47
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour

    Essayez de executer le DBCC SHRINKFILE (N'MonFicherLog',1)  sans "WITH NO_INFOMSGS".

    Ces messages peuvent nous apporter des détails.

    Cordialement,

    Aurel BERA, MSFT
    MSDN Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE.
    S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.

    mardi 3 septembre 2013 08:48
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    mardi 3 septembre 2013 08:55
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Essayez aussi de executer DBCC SHRINKFILE (N'MonFicherLog',1).

    Vous essayez de reduire la taille de fichier a 0. Dans ce cas TRUNCATEONLY sera plus utile.

    Cordialement,

    

    Aurel BERA, MSFT
    MSDN Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE.
    S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.

    mardi 3 septembre 2013 09:39
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Avec l'option TRUNCATEONLY, ça ne change rien.

    Et si je mets : DBCC SHRINKFILE (N'xxxx_log',1) ça shrink mais pas au maximum.

    mardi 3 septembre 2013 09:51
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Salut Greg

    J'ai lu en diagonale, continue d'utiliser database_files, car il est possible que master_files renvoie des données ...incorrectes. Les DMV "niveau base" comme database_files sont plus proches de la réalité.

    Ensuite, n'oublie pas que tu shrinkes un fichier à partir de la fin. Quelques checkpoints au milieu des shrinks aideront probablement car tu ne peux pas reduire si ton vlf actif est assez loin dans le fichier.

    Christophe

    Christophe LAPORTE - Independent Consultant & Trainer - SQL Server MVP-MCM

    • Proposé comme réponse Papy Normand mercredi 11 septembre 2013 19:50
    • Non proposé comme réponse Grégory_Nail mercredi 11 septembre 2013 20:39
    mercredi 11 septembre 2013 08:46
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour Christophe,

    Je n'avais pas mis en évidence ce cas avec le CHECKPOINT mais j'avais essayé sans succès, le problème est le même.

    Voila une capture du déroulement :

    Le problème persiste et ce dans n'importe quel environnement (Serveur de production et serveur personnelle sans activité).

    Et oui, le shrink commence par les dernières pages, mais ici comme le montre le loginfo (voir dans les échanges plus haut), seul la 1er page possède des informations.

    mercredi 11 septembre 2013 20:20
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour ,

    Je vous suggère de lire

    http://msdn.microsoft.com/fr-fr/library/ms189493.aspx

    et notamment dans les Notes la partie appellee Réduction des journaux.

    vous y trouverez :

    "<sentencetext xmlns="http://www.w3.org/1999/xhtml">DBCC SHRINKFILE tente de ramener immédiatement la taille de chaque fichier journal physique à la taille cible.</sentencetext>  <sentencetext xmlns="http://www.w3.org/1999/xhtml">Cependant, si une partie du journal logique se trouve dans les journaux virtuels au-delà de la taille cible, le moteur de base de données libère autant d'espace que possible, puis émet un message d'information.</sentencetext>  <sentencetext xmlns="http://www.w3.org/1999/xhtml">Le message décrit les actions à effectuer pour déplacer le journal logique à partir des journaux virtuels à la fin du fichier.</sentencetext>  <sentencetext xmlns="http://www.w3.org/1999/xhtml">Lorsque les actions sont effectuées, DBCC SHRINKFILE peut être utilisé pour libérer l'espace restant.</sentencetext> "

    Ce qui confirme la réponse de Christian.

    Bonne journée

    Mark Post as helpful if it provides any help.Otherwise,leave it as it is.

    mercredi 11 septembre 2013 20:42
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour

    J'ai étudié vos réponses avec un peu de recul. Et je ne comprend pas, j'ai bien conscience que le shrink de log marche en déplaçant les dernières pages vides.

    Ici, comme je le montre dans mes captures précédentes, la fonction loginfo me remonte que les dernières pages sont vides. 

    Ensuite, pourquoi un shrink en signifiant 0 comme taille a atteindre n'a aucune conséquence alors qu'en spécifiant 1 le shrink s'opère sans atteindre la taille minimum.

    lundi 23 septembre 2013 08:23
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter
    Le problème avait été résolu après redémarrage de l'instance.
    • Marqué comme réponse Grégory_Nail mardi 1 septembre 2015 07:10
    mardi 1 septembre 2015 07:10
    |