Comportement bizarre table mysql

Bonjour,

J'ai récupéré comme d'habitude une sauvegarde de la BDD du 31/05/2018, que j'ai restaurée en local afin de produire des stats d'activités.

J'ai une table "Sortie" qui contient toutes les sorties faites sur les usagers. dans cette table bien sûr il y a une colonne "Date sortie" et une autre colonne "Date d'opération". Bref!

Ma requete pour extraire toutes les sorties du mois de mois de Mai (01/05/2018 au 31/05/2018) me donne 138 enregistrements au lieu de 600 enregistrements en moyenne.

Action 1: je vais en produire et je passe la meme requete ==> 579 enregistrements

Action 2: Je récupère les BDD du 01/06/18; 02/06/18; 03/06/2018; 04/06/2018 que je restaure chacune et en passant la meme requete ==> meme résultat de 138 enregistrements pour Mai 2018

Action 3: J'effectue une sauvegarde en temps réel de la BDD en production, que je restaure en local. Je passe ma requete ==> J'obtiens bien les 579 enregistrements.

je me suis dit que peut-etre que les sorties ont été effectuées en Juin (date opération) pour une date d'effet en Mai. Et bah non toutes les sorties faites ont bien été réalisées en Mai.


Question:
Comment expliquer que les enregistrements dans la table n'apparaissent que ce jour alors qu'elles ont bien été faites en mai dernier?


il y a quelque chose qui m'échappe et c'est la 1ere fois que cela arrive.


Avez-vous une idée sur ce dysfonctionnement mysql?


Merci d'avance

bonjour,

Se prononcer sur le résultat d'une requête sans avoir
- la description des tables
- la requête
- le résultat obtenu, messages d'erreurs éventuels inclus
- le résultat attendu
... c'est mission impossible !

Bsr,

Je comprends:

Structure de la table sortie_membre:

`PK_sortie_membre` int(11) NOT NULL auto_increment,
`FK_motif_sortie` int(11) NOT NULL,
`FK_membre` int(11) NOT NULL,
`FK_utilisateur` int(11) NOT NULL,
`date_sortie_membre` date NOT NULL,
`date_operation` datetime NOT NULL,
`commentaires` text,
`FK_chef_famille` int(11) default NULL,
`FK_motif_orientation` int(11) default NULL,
`FK_service` int(11) NOT NULL,


Requete simple et basique:

Code:

---

SELECT * from sortie_membre where date_sortie_membre between '2018-05-01' and '2018-05-31';

---

Vu que en production comme sur la base restaurée, le nombre de lignes extraites est très modeste, faites en la liste de part et d'autre et comparez ces deux listes
Peut être que les 138 lignes de la base restaurées n'ont aucune intersection avec les 579 lignes de la base prod

Vérifiez le format de date de l'une et l'autre base, vu que c'est votre critère d'extraction (le DDL est il exactement le même sur les deux bases ?)

Salut à tous.

Citation:

---

Envoyé par joeblack7377

J'ai récupéré comme d'habitude une sauvegarde de la BDD du 31/05/2018,

---

Comment avez-vous récupéré votre sauvegarde ?
Est-ce un export depuis phpmyadmin ?
En ligne de commande à partir de mysqldump ?
Récupérer les fichiers système (.frm & .ibd) du répertoire "/data" ?

Citation:

---

Envoyé par joeblack7377

J'ai une table "Sortie" qui contient toutes les sorties faites sur les usagers.

---

Comment savez-vous que vous avez toutes vos sorties ?

Par un simple "select * from sortie_membre".

Citation:

---

Envoyé par joeblack7377

Ma requete pour extraire toutes les sorties du mois de mois de Mai (01/05/2018 au 31/05/2018) me donne 138 enregistrements au lieu de 600 enregistrements en moyenne.

---

Je ne sais pas trop si cela a une quelconque importancee, mais vous n'arrêtez pas de nous donner les dates sous ce format : "dd/mm/yyyy".

Comment se présente vos dates quand vous les chargez dans votre table ?

Citation:

---

Envoyé par joeblack7377

Action 2: Je récupère les BDD du 01/06/18; 02/06/18; 03/06/2018; 04/06/2018 que je restaure chacune et en passant la meme requete ==> meme résultat de 138 enregistrements pour Mai 2018

---

Qu'est-ce que vous entendez par "je récupère les bdd" ?

Dois-je comprendre que vos données viennent de différentes origines ?

Vous dites ensuite "que je restaure". Comment vos données se présentent avant la restauration ? Et comment faites-vous cette restauration ?

Citation:

---

Envoyé par joeblack7377

Action 3: J'effectue une sauvegarde en temps réel de la BDD en production, que je restaure en local. Je passe ma requete ==> J'obtiens bien les 579 enregistrements.

---

Ce qui est en production est donc conforme à vos attentes.

A priori, c'est votre procédure de restauration en développement qui n'est pas conforme.

Citation:

---

Envoyé par joeblack7377

Question: Comment expliquer que les enregistrements dans la table n'apparaissent que ce jour alors qu'elles ont bien été faites en mai dernier?

---

Le mieux est de nous donner un jeu d'essai avant votre restauration, c'est-à-dire vos données à l'état brut.
Comment vous faites cette restauration.

Puis le jeu d'essai avec la requête et la strcture de la table où vous avez un problème avec vos nombres de lignes.

AH oui, on ne parle pas d'enregistrements mais de lignes !

Et question subsidiaire, quelle est la version MySql que vous utilisez ?

@+

Bonjour,
Fanalement j'ai compris le problème mais sans avoir la solution.

Il se trouve que la restauration de la base de données sauvegardées avec mysqldump n'est pas complète au niveau des tables du moins pour cette table.

J'ai beau supprimé la base en recréant une nouvelle vierge pour l'import mais sans résultat.


Cordialement

Salut joeblack7377.

Lors de votre chargement, il se peut que vous ayez eu une erreur de volumétrie ou de timing.

Citation:

---

Envoyé par joeblack7377

Finalement j'ai compris le problème mais sans avoir la solution.

---

Soit :

--> un problème de timing. Dans ce cas, dans le fichier My.Ini, ajoutez ceci dans la section "[mysqld]" :

Code:

---

1 2 3 4 5 6 7

# ------------------------------# # Timeout Configuration # # ------------------------------#   connect-timeout = 600 interactive-timeout = 600 wait-timeout = 600

---

600 = 60 * 10. C'est à dire 10 minutes. Au delà de dix minutes, l'exécution s'arrête.

--> soit un problème dans la taille de vos packets.
Ajoutez ceci dans la section "[mysqld]" et dans "[mysqldump]" :

Code:

---

max-allowed-packet = 16M

---

si cela ne va pas, augmentez 16M à 32M, puis 64M et ainsi de suite.

@+

Bonjour Artemus24,

Merci pour les pistes de solutions.

Pour l'instant j'ai porté ces paramètres: timing à 900 et max-allowed-packet à 32M ==> sans succès. j'ai toujours les données de la table tronqué au même niveau.

Je viens d'augmenter max-allowed-packet à 64M et je verrai le résulat avec la sauvegarde du soir.


Cordialement

Sans attendre le traitement batch de ce soir, j'ai lancé en temps réel le script Backup.

J'ai récupéré et restauré en local la sauvegarde et tout est OK.

Cela fait la 2e fois que je constate que tout est OK avec le lancement du script de sauvegarde en temps réel donc manuellement alors que le meme script lancé le soir en tâche planifiée donne un fichier dump incomplet.

Comment expliquer les erreurs de traitement sur un meme script?


Cordialement

Citation:

---

Cela fait la 2e fois que je constate que tout est OK avec le lancement du script de sauvegarde en temps réel donc manuellement alors que le meme script lancé le soir en tâche planifiée donne un fichier dump incomplet.

Comment expliquer les erreurs de traitement sur un meme script?

---

Y aurait-il un cron qui redémarre la machine ou le service MySQL et qui opérerait pendant la sauvegarde ?

Citation:

---

Envoyé par CinePhil

Y aurait-il un cron qui redémarre la machine ou le service MySQL et qui opérerait pendant la sauvegarde ?

---

Bonjour,

J'ai une tâche planifiée de mise à jour d'états qui se lance à 19h45 et qui prend en tout 1h15 de traitement

Ensuite il y la tâche planifiée de sauvegarde qui démarre à 23h30

Ce fonctionnement est opérationnel depuis 2009 sans soucis particulier jusqu'au problème actuel



Cordialement

Salut à tous.

Quand on fait un batch de nuit, voire une sauvegarde, on se débrouille toujours pour être en mono utilisateur sur la base de données.
Autrement dit, tout utilisateur voulant se connecter après le démarrage des batch de nuit, se verra interdire l'accès à la base de données.
Cela évite beaucoup de problème comme par exemple les blocages à cause des accès concurrents.

Citation:

---

Envoyé par joeblack7377

Ce fonctionnement est opérationnel depuis 2009 sans soucis particulier jusqu'au problème actuel

---

La durée d'un fonctionnment n'est pas la garantie que tout se passe bien.

Par exemple, vous avez une volumétrie moyenne durant ce laps de temps.
Et puis tout d'un coup, la volumétrie explose et vous continuez de procéder de la même façon, sans retoucher à la configuration.
Une solution consiste à mettre des "commit" disons tous les 100 insertions.

Autre cas que vous pouvez rencontrer, vous installer une nouvelle version de MySql, sans mettre à jour la dernière version de phpmyadmin.
Quand vous utilisez l'import, cela ne passe plus. Une seule solution, mettez phpmyadmin à jour.

@+