Le journal n'a pas été tronqué, car les enregistrements du début sont en attente [Résolu]

[Marc_L]

Bonjour tout le monde,

Je viens vers vous car j'ai un gros problème de log qui ne veut pas se vider à cause de :

Le journal n'a pas été tronqué, car les enregistrements du début sont en attente de réplication ou de capture de données modifiées. Assurez-vous que l'Agent de lecture du journal ou qu'un travail de capture est en cours d'exécution,
ou faites appel à sp_repldone pour marquer les transactions comme étant distribuées ou capturées.

Je ne sais donc pas comment commiter ces enregistrements


Je vous colle ici quelques actions que j'ai effectuée sans résultats...

________________________________________________________________________________________________________________________

Code :

BACKUP DATABASE SSIS1 TO DISK = 'e:\sav_db.bak'

donne :

151152 pages traitées pour la base de données 'SSIS1', fichier 'SSIS1' dans le fichier 1.
77166765 pages traitées pour la base de données 'SSIS1', fichier 'SSIS1_log' dans le fichier 1.
BACKUP DATABASE a traité avec succès 77317917 pages en 11373.328*secondes (53.110*Mo/s).

________________________________________________________________________________________________________________________

Code :

BACKUP LOG SSIS1 TO DISK = 'G:\log.bak'

donne maintenant :

77166767 pages traitées pour la base de données 'SSIS1', fichier 'SSIS1_log' dans le fichier 1.
Le journal n'a pas été tronqué, car les enregistrements du début sont en attente de réplication ou de capture de données modifiées. Assurez-vous que l'Agent de lecture du journal ou qu'un travail de capture est en cours d'exécution,
ou faites appel à sp_repldone pour marquer les transactions comme étant distribuées ou capturées.
BACKUP LOG a traité avec succès 77166767 pages en 26733.681*secondes (22.550*Mo/s).

________________________________________________________________________________________________________________________

Quand je fais un :

Code :

DBCC OPENTRAN

, il me donne :

Informations de transaction pour la base de données 'SSIS1'.

Informations sur les transactions*répliquées*:
Plus ancien numéro de séquence d'enregistrement distribué*: (0:0:0)
Plus ancien numéro de séquence d'enregistrement non distribué*: (5956:1141241:1)
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur, contactez l'administrateur système.

________________________________________________________________________________________________________________________
Je fais un :

Code :

1
2
3
4
5
6
7
8
USE SSIS1;
GO
ALTER DATABASE SSIS1
SET SINGLE_USER
WITH ROLLBACK IMMEDIATE;
ALTER DATABASE SSIS1
SET MULTI_USER;
GO

et il me donne :

Les transactions non qualifiées sont annulées. Fin de l'opération (estimation)*: 100%.

________________________________________________________________________________________________________________________
quand je fais un

Code :

1
2
3
4
 
USE SSIS1
go
exec sp_repldone @xactid = NULL, @xact_seqno = NULL, @numtrans = 0, @time = 0, @reset = 1

il me met :

Msg*18757, Niveau*16, État*1, Procédure*sp_repldone, Ligne*1
Impossible d'exécuter la procédure. La base de données n'est pas publiée. Exécutez la procédure dans une base de données publiée pour la réplication.

________________________________________________________________________________________________________________________

Je fais un

Code :

1
2
3
USE ssis1
go
exec sp_replicationdboption 'ssis1','publish','true'

Il me donne :

Msg*20028, Niveau*16, État*1, Procédure*sp_MSpublishdb, Ligne*56
Le serveur de distribution n'a pas été correctement installé. Impossible d'activer la base de données pour la publication.
L'option de réplication 'publish' de la base de données 'ssis1' est déjà définie sur FALSE.

________________________________________________________________________________________________________________________

Je fais un

Code :

1
2
3
4
USE SSIS1
Go
EXEC sys.sp_cdc_enable_db
GO

pas de résultats ...
________________________________________________________________________________________________________________________

Et là j'arrête car je commence à faire du grand n'importe quoi ...

Meerci d'avance.

[elsuket]

Bonjour,

La base de données est-elle répliquée, ou utilisez vous la fonctionnalité de Change Data Capture ?

Dans tous les cas, que donne :

Code :

1
2
3
SELECT	log_reuse_wait_desc
FROM	sys.DATABASES
WHERE	name =  'maBD'

@++

[Marc_L]

Bonjour elsuket,

La base de données est-elle répliquée, ou utilisez vous la fonctionnalité de Change Data Capture ?

Ni l'un ni l'autre ...

J'avais lancé le

Code :

1
2
3
4
USE SSIS1
Go
EXEC sys.sp_cdc_enable_db
GO

au cas où mais cela n'a rien changé ...

Dans tous les cas, que donne :

Code :

Résultat vide

[Marc_L]

Bon et bien finalement, c'est ok ...

J'ai fait ceci :

Code :

EXEC sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time = 0, @reset = 1

plus ceci :

Code :

1
2
3
4
 USE SSIS1
 DBCC shrinkfile(SSIS1_log,50)
 DBCC SHRINKDATABASE (SSIS1,10)
 DBCC SHRINKDATABASE (SSIS1,truncateonly)

Maintenant, je ne sais pas du tout si une partie de la solution s'est retrouvée dans les 36 manœuvres que j'ai opéré en vain juste avant ... ;-)

enfin, toujours est-il que le log est passé de 600Gb à 12Gb.

[elsuket]

Résultat vide

Il aurait fallu changer le maBD par le nom de votre base de données

Code :

1
2
3
DBCC shrinkfile(SSIS1_log,50)
 DBCC SHRINKDATABASE (SSIS1,10)
 DBCC SHRINKDATABASE (SSIS1,truncateonly)

Quel est le mode de restauration de votre base de données ?
Je parie cher pour que ce soit FULL. Pour le trouver :

Code :

1
2
3
SELECT	recovery_model_desc
FROM	sys.DATABASES
WHERE	name = 'maBD'

Si c'est le cas, vous ne gérez probablement pas le fichier du journal de transactions comme il se doit, c'est à dire en prenant des sauvegardes de celui-ci, soit par un job, soit par un plan de maintenance, et ce à intervalles réguliers.

Enfin faire rétrécir les fichiers d'une base de données est une manœuvre d'urgence qui ne doit être exécutée que par manque d'espace disque.
Les faire rétrécir régulièrement provoque, en plus de la fragmentation physique du fichier lors de leur nouveau grossissement, une attente générale à chaque grossissement de fichier.
Cet espace sera de toute façon repris par SQL Server, tôt ou tard.

Pour reprendre la métaphore de SQLPro sur le sujet, c'est comme si je faisais un parking tout neuf, et que je cassais les places à coup de marteau-piqueur après que chaque voiture se soit garée dessus, pour la re-goudronner juste ensuite ...

Ensuite en ce qui concerne le fichier du journal des transactions, il est découpé en morceaux logiques appelés fichiers journaux virtuels (VLF dans la littérature).
Plus votre fichier physique en contient, plus la base de donnée sera longue à restaurer.
Plus grave : si la base de données subit des transactions qui manipulent un volume de données conséquent, elles en seront un peu ralenties.
Je n'ai pas fait le test, mais je suis même quasiment certain que la sauvegarde du fichier du journal des transactions est plus rapide s'il y a peu de VLFs.
Un peu plus sur le sujet ici

Le mieux est donc de tailler les fichiers de la base de données lors de sa création, et de paramétrer le grossissement des fichiers pour le cas où elle viendrait à grossir.
C'est à dire de ne pas laisser le paramétrage par défaut, qui est de un Mo pour les fichiers de données, et de 10% pour le fichier du journal des transactions.
Pour ma part je mets tout à 1Go, mais le choix vous appartient.

Enfin, ne lancez pas des instructions dont vous ne connaissez ni les tenants, ni les aboutissants.
La procédure stockée sys.sp_cdc_enable_db active la base de données pour la capture de changements de données.
C'est à dire que pour les tables pour lesquelles cette fonctionnalité est aussi activée, tous les changements sont tracés, avec une table de "trace" pour chaque table auditée, créée dans le schéma cdc.
Ces tables contiennent toutes les valeurs de toutes les colonnes de la table auditée pour chaque changement, plus quelques colonnes "système".
Pour certains UPDATE, on y retrouve deux lignes.
Tout ça pour dire que vous pouvez vous retrouver avec un volume de données conséquent sans savoir pourquoi, et alors rétrécir les fichiers, encore une fois ...

@++

[elsuket]

Seriez-vous dans le cas suivant ?

@++