Dans le fichier de log joint, il faudrait supprimer 82 000 occurences des 2 lignes suivantes, ce qui permettrait d’alléger grandement le log
delete from m_translate where row_id=56671;
– dead link detected m_translate.tsl_id / rule ‘restrict/cascade delete’ of link DocIndex → TranslateDocIndex
Je souhaite savoir s’il est possible de désactiver les traces générées par l’outil d’Audit sur cette objet dans Simplicité. Nous aimerions réduire la quantité de logs produits par cet outil pour des raisons de performance et de gestion des données.
Ce n’est jamais une bonne stratégie de vouloir ignorer des erreurs, surtout des erreurs remontées par un mécanisme d’audit… Il faut résoudre les problèmes, pas les masquer
Pour commencer, afin de pouvoir assurer du support dans de bonnes conditions, merci d’indiquer la version exacte que vous utilisez
Je comprends votre point de vue concernant l’importance de résoudre les erreurs plutôt que de les ignorer. Toutefois, dans notre cas, il s’agit de minimiser l’impact des traces d’audit sur les performances, tout en nous assurant que les problèmes sous-jacents sont résolus.
Pour répondre à votre demande, voici la version exacte que nous utilisons actuellement : Simplicité 5.3.66
Nous restons ouverts à vos conseils concernant la gestion de ces traces d’audit,
OK vous êtes à jour sur la branche de maintenance long terme v5, je voulais déjà m’en assurer.
Pour ce qui est des erreurs remontées par l’audit, celles de ce type:
-- dead link detected m_translate.tsl_id / rule 'restrict/cascade delete' of link ObjectInternal --> TranslateObject
delete from m_translate where row_id=100;
indiquent le statement SQL destiné à résoudre le problème, il suffit donc d’executer les statements en question sur la base et les erreurs seront résolues et n’apparaitront plus dans l’audit suivant
Par contre je suis extrêmement étonné par le nombre très important d’erreurs de ce type, donc avant de passer ces statements correctifs je voudrais faire quelques vérifications
Pouvez vous me donner le résultat de ces requêtes:
select tsl_type, count(*) from m_translate group by tsl_type;
select count(*) from m_field;
select count(*) from m_object;
select count(*) from m_objfield;
Suite à votre demande, voici les résultats des requêtes que vous m’avez indiquées :
select tsl_type, count(*) from m_translate group by tsl_type
# TSL_TYPE C2
1 O 499
2 F 2825
3 R 30
4 L 564
5 Z 409
6 A 348
7 K 21
8 C 22
9 S 26
10 Q 18
11 V 18
12 T 106
13 P 14
14 W 10
15 B 35
16 U 1
select count(*) from m_field
# C1
1 1651
select count(*) from m_object
# C1
1 284
select count(*) from m_objfield
# C1
1 2664
Je ne comprends pas votre logique… J’ai besoin que vous exécutiez les requêtes demandées sur la même instance que celle où vous avez vos erreurs d’audit, sinon on parle de choses qui n’ont rien à voir…
En tout ca, à ce stade, n’exécutez aucun statement de deleteà ce stade car nous somme en train d’investiguer le comportement de l’audit sur la version 5.3
A titre conservatoire, pour éviter les problèmes, on a retiré l’analyse de la table m_translate de l’audit v5, ce sera releasé dans la prochaine révision de maintenance de la v5 (5.3.67)
J’ai basculé temporairement l’instance https://vision360dev.tdf.simplicite.io sur la branche “preview” de la prochaine révision => L’audit ne remonte plus de “dead links” non légitimes sur cette instance (j’ai supprimé les quelques uns restants qui étaient légitimes):
