Version imprimable
Bonjour,
J'ai l'impression que par moment, certains select ne renvoient aucun résultat alors qu'il y a bien des données en table (plus de 160 000 lignes).
Je n'ai aucun retour d'erreur, et le log de postgre ne montre rien du tout non plus.
Pourriez vous me donner des pistes pour chercher à comprendre ce qu'il se passe ?
Merci d'avance !
Note : j'utilise la version 9.3.5 sur AIX
Bonjour,
Il faudrait détailler un peu le contexte.
Qu'est qui vous mène a cette conclusion, quel tests avez vous effectués,...
Bonjour,
J'ai un traitement qui régulièrement extrait le contenu de la table dans un fichier. Et j'ai pu remarquer que très occasionnellement ce fichier est vide et qu'après il est a nouveau rempli. Or mes programmes qui tournent sur ce système ne savent pas ré-générer ces données donc si la table est vide à un moment, elle le restera tant que les utilisateurs n'y re-créeront pas de lignes et les utilisateurs vréent les lignes 1 par 1 alors avant d'arriver a 165000 et avec des id croissants.
J'ai regarder tous mes logs aux heures de génération des fichiers vides et je n'ai rien trouvé : aucune erreur aucun warning.
Donc je cherche des pistes ou des moyens de controle ...
Bonjour,
Ne serait-ce pas tout simplement lié à des commits périodiques tous les n enregistrements, avant le 1er commit, votre table est vide (sauf à faire des requetes with UR)
Non, la table contient 165000 ligne a l'origine, les utilisateurs n'en créent que quelques dizaines par jour.Citation:
Envoyé par escartefigue
Pour info, voici la requête d'export :
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24SELECT COALESCE(a."NUMSUITEKEY", 0) AS COL1, a."COMMENTAIREFACTURATION" AS COL2, a."FICHIERIMAGE" AS COL3, a."NOMBREOUBASE" AS COL4, a."TAUXOUMONTANT" AS COL5, a."MOISPAIE" AS COL6, COALESCE(a."NUMCONTRAT", 0) AS COL7, a."ETATTRAITEMENT" AS COL8, a."NUMERISE" AS COL9, a."NOMBREOUBASE2" AS COL10, a."RUBRIQUE" AS COL11, a."ORIGINE" AS COL12, a."NUMFACTURE" AS COL13, a."NUMPAIE" AS COL14, a."LIBELLE" AS COL15, a."DATEFACTURE" AS COL16, COALESCE(a."DATERUB", ('0001-01-01'::DATE)) AS COL17, a."TAUXOUMONTANT2" AS COL18 FROM PACA."INTERIM@CONTRATBORDEREAURUBRIQUE" a WHERE (a."RUBRIQUE" <> 0) ORDER BY COL7 ASC, COL17 ASC, COL1 ASC FOR READ ONLY
Salut
Qui entrENT les données dans la table et à quel moment (étape)?
Qui exécutENT la requête d'export et à quel moment (étape)? L'export se fait-il après le vidage du fichier?
Qui lit le fichier et à que moment (étape)? Le fichier est-il partagé?
@+
Il y a 6 mois, on a importé 165000 lignes de données d'un ancien système.Citation:
Envoyé par alassanediakite
Depuis, chaque jour les utilisateurs saisissent et/ou modifient quelques lignes (une par une comme expliqué dans mon post précédent)
l'export est déclenché par une interface socket depuis mon ancien système. Ca se traduit par : on sort tous les utilisateurs des programmes de saisie, puis on génère le ficher à partir de la requete présentée ci-dessus. Si un traitement d'export est déjà en cours, on jette avec une erreur.Citation:
Envoyé par alassanediakite
le fichier est lu par un script bash une fois que l'export est terminé (une fois le fichier généré, on crée un fichier de flag en plus pour que le script bash sache qu'il peut lire les données). Tout se trouve sur le même système IBM AIX 7. Le fichier n'est pas partagé et il n'a qu'un seul lecteur potentiel qui ne le supprime même pas.Citation:
Envoyé par alassanediakite
Salut
Je soupçonne leCitation:
Envoyé par gRRosminet
comme responsable du fichier vide.Code:WHERE (a."RUBRIQUE" <> 0)
@+
malheureusement ce n'est pas ça car il faudrait un traitement qui passe ce champ rubrique à 0 sur toutes les lignes or je n'ai aucun traitement qui fasse des modifications par lot sur ces lignes. Et plus fort encore, il faudrait que la valeur de ce champ soit restaurée à postériori (et c'est une valeur que seul l'humain peut décider et il n'y a meme pas assez d'infos sur la ligne pour deviner ce que ça aurait pu être).
C'est en marge de votre sujet mais si votre colonne a.rubrique est indexée et qu'il n'y a pas de valeur < 0, vous auriez intérêt à remplacer
ParCode:WHERE (a."RUBRIQUE" <> 0)
Pour revenir à votre problème, si votre requête est encapsulée dans un traitement, on peut imaginer que parfois, le traitement ouvre le fichier résultant, mais ne va pas jusqu'à la requête d'extraction (on peut imaginer toutes sortes de raisons), et du coup, vous avez un fichier videCode:WHERE (a."RUBRIQUE" > 0)
Comme la requête ne s'est pas exécutée, vous n'avez aucune trace de plantage coté base de données.
C'est effectivement une des possibilités que j'avais envisagées, mais je n'ai pas trouvé d'erreurs dans les logs de mon appli non plus :'(Citation:
Envoyé par escartefigue
Peut être pouvez vous activer une trace pas à pas sur un environnement bis genre recette ou pré-prod et surveiller les résultats ?