db2 effacer l'horodatage de l'historique et supprimer n'ayant aucun effet?

Question

J'ai besoin de votre aide avec celui-ci: Je suis sur DB2 luw 10.5.8 et ai mis logarchmeth1 à tsm. J'ai remarqué que mon chemin de connexion est plein (seulement 10% de l'espace disponible restant) et j'ai donc décidé d'utiliser la commande db2 prune history pour libérer de l'espace.

Voici la commande je:

db2 prune history 20170813 and delete 

J'avais l'impression que cette commande permettrait de libérer un peu d'espace en supprimant tous les fichiers journaux avant ou égale à la date indiquée. Malheureusement, cela n'a pas fonctionné de cette façon. L'espace libre disponible dans mon chemin de connexion est resté inchangé à 10%.

J'ai aussi essayé la commande logfile pruneau depracated (même résultat):

db2 prune logfile prior to S0000100.LOG 

Que puis-je faire pour libérer un peu d'espace dans mon logpath? Des idées?

Answer 1

Avez-vous vérifié que l'archivage vers TSM se terminait correctement? En outre, vous devrez peut-être archiver manuellement tous les fichiers journaux terminés avant d'activer TSM.

Vous pouvez voir ce tsm-archive-completion dans les vues db2diag et db_history. Si vous définissez AUTO_DEL_REC_OBJ sur activé, DB2 doit effectuer l'élagage à la fin d'une sauvegarde DB2 en fonction des paramètres associés. En cas d'indisponibilité de TSM, les fichiers journaux à archiver resteront dans le chemin du journal actif (sauf si vous définissez en plus FAILARCHPATH) jusqu'à ce que le système de fichiers pour les journaux actifs se remplisse ou TSM-resumes-service (selon le cas premier). DB2 réessayera continuellement TSM et reprendra automatiquement l'archivage lorsque TSM répondra.

Assurez-vous que votre système de fichiers pour les journaux actifs (et/ou le système de fichiers sans chemin d'accès sans échec) est suffisamment grand pour tolérer une indisponibilité TSM de la durée choisie.