DBCC SHRINKFILE sur une base en replication

Bonjour,
pouvons-nous lancer un DBCC SHRINKFILE sur une base pour réduire le fichier des logs, alors que celle-ci est configurée dans une réplication ?
Et que cette réplication est active ?
L'opération est passée et la log est bien réduite. J'ai lu quelque part, que tant que les opérations n'ont pas été répliquées, on ne peut pas la réduire, comme si l'opération n'avait pas encore été commitée. Donc que ça marcherait exactement de la même manière qu'une log d'une base non répliquée. Donc logiquement il ne devrait y avoir aucun problème. Mais j'aimerai bien l'avis de quelqu'un qui l'aurait déjà fait..

Bonjour,

Quelques pistes :

Je suppose que tu fais allusion à une base qui est publiée, sur ton publisher ?
Ta réplication est-elle transactionnelle ? merge ?

si tu parles d'une base publiée, en réplication transactionnelle, tu peux tronquer ton log. Tu peux d'ailleurs, rendre publisher transactionnel une base qui est en mode de recovery simple... Ton log va certainement grandir à nouveau si pour une raison ou une autre la réplication ne peut se faire et les transactions s'accumulent dans le log sans pouvoir être répliquées.

Pour regarder ce qui se passe dans ton log : DBCC OPENTRAN. Pour voir les transactions non encore répliquées : sp_repltrans.
Parfois une transaction de réplication reste ouverte. Tu peux l'arrêter en utilisant sp_repldone.

Pour l'avis, évite autant que possible de faire des shrinkfile, et si tu le fais, ne réduit pas complètement le log, laisse-lui la place dont tu penses qu'il a besoin pour pouvoir travailler à l'aise. Ainsi tu diminues le nombre de VLF, la fragmentation de ton disque, et une baisse de performance lors des augmentations de taille automatiques.

--
Rudi Bruchez

Je viens juste de récupérer ces bases, et ce qui m'a paru bizarre, c'est q'elles soient en mode de récupération complète, et qu'aucun job de sauvegarde de logs n'était programmé. Du coup, les logs faisaient 7 fois la taille de la base (qui faisait 1,5 Gb). Ce qui me paraissait un peu beaucoup ... Du coup, le DBCC SHRINKFILE est bien passé et a bien réduit le fichier de logs. Mais ma question est:
Si l'opération a réussi, et donc que le fichier a bien été réduit, est-ce que ça peut faire planter la réplication car physiquement la base a changé ?

pas de souci, la taille physique du fichier de log n'a aucun impact sur la bonne marche de la réplication (sauf quand ce log est plein ;) ).

Par contre, je te suggère de planifier une stratégie de backup, afin d'éviter le grossissement des logs, et bien sûr des pertes de données.

--
Rudi Bruchez

Merci de ta réponse ... Oui, la stratégie de sauvegarde va de toutes façons être changée. C'est pour ça (entre autres) qu'on m'a demandé de m'en occuper. Je voulais juste avoir des tailles de bases acceptables surtout pour gagner de la place.... En "shrinkant" les logs, j'ai gagné dans les 13Gb !!! Donc c'est autant de place de gagnée pour les backups !!

Je suis confronté à un autre dilème ... :(
Puis-je sans problèmes réorganiser une base qui est publiée ? La base de publication ? La base abonnée ?
(commande utilisée : DBCC DBREINDEX)

Hello,

même chose. La réorganisation de l'index se fait sur les pages (sur le stockage), pas sur l'organisation des données elle-mêmes telles qu'elles sont répliquées. Ca peut avoir un effet de blocage temporairement comme sur des bases non répliquées, mais la réplication ne va pas être mise en erreur.
Même chose pour la base abonnée.