Soit un fichier de 600Mo, contenant environ 2.5millions de fiches, taille
d'enregistrement 172 octets
Une routine de suppression:
chercher toutes les fiches correspondant au filtre, mettre les n°
d'enregistrement dans un tableau
- debut mesure
pour tout rec de montableau, hsupprime(monfichier, rec)
- fin mesure
pc avec 512Mo + 768Mo de swap, essai en local
Avec 2 clé (une dateheure, et un idunique):
taille fichier index 82Mo; 2 index; 0s pour hsupprimer 2000 fiches
je coche 2 champ numérique (sur 4) comme clé avec doublon :
taille fichier index 154Mo;4 index; 13s pour 2000 fiches
je coche 2 champ numérique (sur 4) comme clé avec doublon:
taille fichier index: 226 Mo: 6 index; 34s pour 2000 fiches
pour finir par un magistral:
taille fichier index: 1Go: 18 index, 200s pour 2000 fiches
d'ailleurs à ce stade, la reindexation prend environ 40minutes
ca augmente en fonction du nombre de clé, et avec le cpu qui fout rien
pendant la suppression.
je crois que je vais essayer de programmer :
copie du ORG.FIC en SAV.FIC
création d'un hdecritfichier identique à ORG.FIC mais sans les index pour
ouverture du SAV.FIC
suppression dans le SAV
reindexation du sav
déplacement du SAV.FIC+NDX en ORG.FIC+NDX
mais j'en ai franchement raz les sacoches de perdre du temps à contourner
les problèmes d'un outil qui est censé nous en faire gagner.
Soit un fichier de 600Mo, contenant environ 2.5millions de fiches, taille d'enregistrement 172 octets Une routine de suppression: chercher toutes les fiches correspondant au filtre, mettre les n° d'enregistrement dans un tableau - debut mesure pour tout rec de montableau, hsupprime(monfichier, rec) - fin mesure
pc avec 512Mo + 768Mo de swap, essai en local
Avec 2 clé (une dateheure, et un idunique): taille fichier index 82Mo; 2 index; 0s pour hsupprimer 2000 fich es je coche 2 champ numérique (sur 4) comme clé avec doublon : taille fichier index 154Mo;4 index; 13s pour 2000 fiches je coche 2 champ numérique (sur 4) comme clé avec doublon: taille fichier index: 226 Mo: 6 index; 34s pour 2000 fiches
pour finir par un magistral: taille fichier index: 1Go: 18 index, 200s pour 2000 fiches d'ailleurs à ce stade, la reindexation prend environ 40minutes
ca augmente en fonction du nombre de clé, et avec le cpu qui fout rien pendant la suppression.
je crois que je vais essayer de programmer : copie du ORG.FIC en SAV.FIC création d'un hdecritfichier identique à ORG.FIC mais sans les ind ex pour ouverture du SAV.FIC suppression dans le SAV reindexation du sav déplacement du SAV.FIC+NDX en ORG.FIC+NDX
mais j'en ai franchement raz les sacoches de perdre du temps à contourn er les problèmes d'un outil qui est censé nous en faire gagner.
18 indexes pour un enreg de 172 caractères de long c'est pas un peu beaucoup ?
Une table pour moi c'est 1 index unique par PK, 1 index avec doublon sur les FK 1 index unique sur la donnée fonctionnelle parfois un index de perf
Mais 18 indexes ...
Sinon c'est un peu normal que plus il y a d'indexes plus le temps de suppression (à fortiori modification, insertion) est long. Si tu prend ton fichier de 226Mo avec 18 indexes pour chacun de tes 2000 delete il doit (si le stockage HF est en b-tree) : - rechercher l'adresse dans le fichier pour ton index - rechercher l'adresse de ta données dans son arbre (index b-tree) - recalculer l'arbre si il est déséquilibré et le restocké
soit : 200s / 2000 / 18 = 5 millisecondes pour les 3 actions ci dessus sur fiches. C'est pas délirant à mon sens.
patrice a écrit :
Bonjour
Soit un fichier de 600Mo, contenant environ 2.5millions de fiches, taille
d'enregistrement 172 octets
Une routine de suppression:
chercher toutes les fiches correspondant au filtre, mettre les n°
d'enregistrement dans un tableau
- debut mesure
pour tout rec de montableau, hsupprime(monfichier, rec)
- fin mesure
pc avec 512Mo + 768Mo de swap, essai en local
Avec 2 clé (une dateheure, et un idunique):
taille fichier index 82Mo; 2 index; 0s pour hsupprimer 2000 fich es
je coche 2 champ numérique (sur 4) comme clé avec doublon :
taille fichier index 154Mo;4 index; 13s pour 2000 fiches
je coche 2 champ numérique (sur 4) comme clé avec doublon:
taille fichier index: 226 Mo: 6 index; 34s pour 2000 fiches
pour finir par un magistral:
taille fichier index: 1Go: 18 index, 200s pour 2000 fiches
d'ailleurs à ce stade, la reindexation prend environ 40minutes
ca augmente en fonction du nombre de clé, et avec le cpu qui fout rien
pendant la suppression.
je crois que je vais essayer de programmer :
copie du ORG.FIC en SAV.FIC
création d'un hdecritfichier identique à ORG.FIC mais sans les ind ex pour
ouverture du SAV.FIC
suppression dans le SAV
reindexation du sav
déplacement du SAV.FIC+NDX en ORG.FIC+NDX
mais j'en ai franchement raz les sacoches de perdre du temps à contourn er
les problèmes d'un outil qui est censé nous en faire gagner.
18 indexes pour un enreg de 172 caractères de long c'est pas un peu
beaucoup ?
Une table pour moi c'est
1 index unique par PK,
1 index avec doublon sur les FK
1 index unique sur la donnée fonctionnelle
parfois un index de perf
Mais 18 indexes ...
Sinon c'est un peu normal que plus il y a d'indexes plus le temps de
suppression (à fortiori modification, insertion) est long. Si tu prend
ton fichier de 226Mo avec 18 indexes pour chacun de tes 2000 delete il
doit (si le stockage HF est en b-tree) :
- rechercher l'adresse dans le fichier pour ton index
- rechercher l'adresse de ta données dans son arbre (index b-tree)
- recalculer l'arbre si il est déséquilibré et le restocké
soit : 200s / 2000 / 18 = 5 millisecondes pour les 3 actions ci dessus
sur fiches. C'est pas délirant à mon sens.
Soit un fichier de 600Mo, contenant environ 2.5millions de fiches, taille d'enregistrement 172 octets Une routine de suppression: chercher toutes les fiches correspondant au filtre, mettre les n° d'enregistrement dans un tableau - debut mesure pour tout rec de montableau, hsupprime(monfichier, rec) - fin mesure
pc avec 512Mo + 768Mo de swap, essai en local
Avec 2 clé (une dateheure, et un idunique): taille fichier index 82Mo; 2 index; 0s pour hsupprimer 2000 fich es je coche 2 champ numérique (sur 4) comme clé avec doublon : taille fichier index 154Mo;4 index; 13s pour 2000 fiches je coche 2 champ numérique (sur 4) comme clé avec doublon: taille fichier index: 226 Mo: 6 index; 34s pour 2000 fiches
pour finir par un magistral: taille fichier index: 1Go: 18 index, 200s pour 2000 fiches d'ailleurs à ce stade, la reindexation prend environ 40minutes
ca augmente en fonction du nombre de clé, et avec le cpu qui fout rien pendant la suppression.
je crois que je vais essayer de programmer : copie du ORG.FIC en SAV.FIC création d'un hdecritfichier identique à ORG.FIC mais sans les ind ex pour ouverture du SAV.FIC suppression dans le SAV reindexation du sav déplacement du SAV.FIC+NDX en ORG.FIC+NDX
mais j'en ai franchement raz les sacoches de perdre du temps à contourn er les problèmes d'un outil qui est censé nous en faire gagner.
18 indexes pour un enreg de 172 caractères de long c'est pas un peu beaucoup ?
Une table pour moi c'est 1 index unique par PK, 1 index avec doublon sur les FK 1 index unique sur la donnée fonctionnelle parfois un index de perf
Mais 18 indexes ...
Sinon c'est un peu normal que plus il y a d'indexes plus le temps de suppression (à fortiori modification, insertion) est long. Si tu prend ton fichier de 226Mo avec 18 indexes pour chacun de tes 2000 delete il doit (si le stockage HF est en b-tree) : - rechercher l'adresse dans le fichier pour ton index - rechercher l'adresse de ta données dans son arbre (index b-tree) - recalculer l'arbre si il est déséquilibré et le restocké
soit : 200s / 2000 / 18 = 5 millisecondes pour les 3 actions ci dessus sur fiches. C'est pas délirant à mon sens.
patrice
a écrit dans le message de news:
18 indexes pour un enreg de 172 caractères de long c'est pas un peu beaucoup ?
ben c'est un fichier de données de fab, donc y'a toutes les clés externes des différents producteurs + lot de fab + ... plus toutes les clés composées pour les traitements (sinon vu le nombre de données ca rame trop)
Sinon c'est un peu normal que plus il y a d'indexes plus le temps de suppression (à fortiori modification, insertion) est long. Si tu prend ton fichier de 226Mo avec 18 indexes pour chacun de tes 2000 delete il doit (si le stockage HF est en b-tree) :
ce qui me gene plus c'est que le cpu fout rien
<elecoest@gmail.com> a écrit dans le message de
news:1164637875.329596.294830@j44g2000cwa.googlegroups.com...
18 indexes pour un enreg de 172 caractères de long c'est pas un peu
beaucoup ?
ben c'est un fichier de données de fab, donc y'a toutes les clés externes
des différents producteurs + lot de fab + ...
plus toutes les clés composées pour les traitements (sinon vu le nombre de
données ca rame trop)
Sinon c'est un peu normal que plus il y a d'indexes plus le temps de
suppression (à fortiori modification, insertion) est long. Si tu prend
ton fichier de 226Mo avec 18 indexes pour chacun de tes 2000 delete il
doit (si le stockage HF est en b-tree) :
18 indexes pour un enreg de 172 caractères de long c'est pas un peu beaucoup ?
ben c'est un fichier de données de fab, donc y'a toutes les clés externes des différents producteurs + lot de fab + ... plus toutes les clés composées pour les traitements (sinon vu le nombre de données ca rame trop)
Sinon c'est un peu normal que plus il y a d'indexes plus le temps de suppression (à fortiori modification, insertion) est long. Si tu prend ton fichier de 226Mo avec 18 indexes pour chacun de tes 2000 delete il doit (si le stockage HF est en b-tree) :
ce qui me gene plus c'est que le cpu fout rien
elecoest
patrice a écrit :
a écrit dans le message de news: >18 indexes pour un enreg de 172 caractères de long c'est pas un peu >beaucoup ? ben c'est un fichier de données de fab, donc y'a toutes les clés exte rnes des différents producteurs + lot de fab + ... plus toutes les clés composées pour les traitements (sinon vu le nomb re de données ca rame trop)
Si tu avais la description de la table ce serait interssant. Tu ne peux pas restreindre tes ensembles à traiter avec des tables temporaires ? ce serait peut être plus rapide.
>Sinon c'est un peu normal que plus il y a d'indexes plus le temps de >suppression (à fortiori modification, insertion) est long. Si tu prend >ton fichier de 226Mo avec 18 indexes pour chacun de tes 2000 delete il >doit (si le stockage HF est en b-tree) :
ce qui me gene plus c'est que le cpu fout rien
Normal il passe tout son temps en temps accès disque ;)
patrice a écrit :
<elecoest@gmail.com> a écrit dans le message de
news:1164637875.329596.294830@j44g2000cwa.googlegroups.com...
>18 indexes pour un enreg de 172 caractères de long c'est pas un peu
>beaucoup ?
ben c'est un fichier de données de fab, donc y'a toutes les clés exte rnes
des différents producteurs + lot de fab + ...
plus toutes les clés composées pour les traitements (sinon vu le nomb re de
données ca rame trop)
Si tu avais la description de la table ce serait interssant. Tu ne peux
pas restreindre tes ensembles à traiter avec des tables temporaires ?
ce serait peut être plus rapide.
>Sinon c'est un peu normal que plus il y a d'indexes plus le temps de
>suppression (à fortiori modification, insertion) est long. Si tu prend
>ton fichier de 226Mo avec 18 indexes pour chacun de tes 2000 delete il
>doit (si le stockage HF est en b-tree) :
ce qui me gene plus c'est que le cpu fout rien
Normal il passe tout son temps en temps accès disque ;)
a écrit dans le message de news: >18 indexes pour un enreg de 172 caractères de long c'est pas un peu >beaucoup ? ben c'est un fichier de données de fab, donc y'a toutes les clés exte rnes des différents producteurs + lot de fab + ... plus toutes les clés composées pour les traitements (sinon vu le nomb re de données ca rame trop)
Si tu avais la description de la table ce serait interssant. Tu ne peux pas restreindre tes ensembles à traiter avec des tables temporaires ? ce serait peut être plus rapide.
>Sinon c'est un peu normal que plus il y a d'indexes plus le temps de >suppression (à fortiori modification, insertion) est long. Si tu prend >ton fichier de 226Mo avec 18 indexes pour chacun de tes 2000 delete il >doit (si le stockage HF est en b-tree) :
ce qui me gene plus c'est que le cpu fout rien
Normal il passe tout son temps en temps accès disque ;)
patrice
"patrice" a écrit dans le message de news:456af0b1$0$27094$
je crois que je vais essayer de programmer : copie du ORG.FIC en SAV.FIC création d'un hdecritfichier identique à ORG.FIC mais sans les index
pour
ouverture du SAV.FIC suppression dans le SAV reindexation du sav déplacement du SAV.FIC+NDX en ORG.FIC+NDX
j'arrive bien à créer un fichier identique sans les clés pour effectuer mon traitement, mais après je sais pas comment remettre les rubriques clés :(( pour regenérer l'index
"patrice" <patrice_labracherie_nospam@free.fr> a écrit dans le message de
news:456af0b1$0$27094$426a34cc@news.free.fr...
je crois que je vais essayer de programmer :
copie du ORG.FIC en SAV.FIC
création d'un hdecritfichier identique à ORG.FIC mais sans les index
pour
ouverture du SAV.FIC
suppression dans le SAV
reindexation du sav
déplacement du SAV.FIC+NDX en ORG.FIC+NDX
j'arrive bien à créer un fichier identique sans les clés pour effectuer mon
traitement, mais après je sais pas comment remettre les rubriques clés :((
pour regenérer l'index
"patrice" a écrit dans le message de news:456af0b1$0$27094$
je crois que je vais essayer de programmer : copie du ORG.FIC en SAV.FIC création d'un hdecritfichier identique à ORG.FIC mais sans les index
pour
ouverture du SAV.FIC suppression dans le SAV reindexation du sav déplacement du SAV.FIC+NDX en ORG.FIC+NDX
j'arrive bien à créer un fichier identique sans les clés pour effectuer mon traitement, mais après je sais pas comment remettre les rubriques clés :(( pour regenérer l'index
Francis DUHAUT
Heu ... tu peux faire une requete suppression ???
"patrice" a écrit dans le message de news: 456af0b1$0$27094$
Bonjour
Soit un fichier de 600Mo, contenant environ 2.5millions de fiches, taille d'enregistrement 172 octets Une routine de suppression: chercher toutes les fiches correspondant au filtre, mettre les n° d'enregistrement dans un tableau - debut mesure pour tout rec de montableau, hsupprime(monfichier, rec) - fin mesure
pc avec 512Mo + 768Mo de swap, essai en local
Avec 2 clé (une dateheure, et un idunique): taille fichier index 82Mo; 2 index; 0s pour hsupprimer 2000 fiches je coche 2 champ numérique (sur 4) comme clé avec doublon : taille fichier index 154Mo;4 index; 13s pour 2000 fiches je coche 2 champ numérique (sur 4) comme clé avec doublon: taille fichier index: 226 Mo: 6 index; 34s pour 2000 fiches
pour finir par un magistral: taille fichier index: 1Go: 18 index, 200s pour 2000 fiches d'ailleurs à ce stade, la reindexation prend environ 40minutes
ca augmente en fonction du nombre de clé, et avec le cpu qui fout rien pendant la suppression.
je crois que je vais essayer de programmer : copie du ORG.FIC en SAV.FIC création d'un hdecritfichier identique à ORG.FIC mais sans les index pour ouverture du SAV.FIC suppression dans le SAV reindexation du sav déplacement du SAV.FIC+NDX en ORG.FIC+NDX
mais j'en ai franchement raz les sacoches de perdre du temps à contourner les problèmes d'un outil qui est censé nous en faire gagner.
Heu ... tu peux faire une requete suppression ???
"patrice" <patrice_labracherie_nospam@free.fr> a écrit dans le message de
news: 456af0b1$0$27094$426a34cc@news.free.fr...
Bonjour
Soit un fichier de 600Mo, contenant environ 2.5millions de fiches, taille
d'enregistrement 172 octets
Une routine de suppression:
chercher toutes les fiches correspondant au filtre, mettre les n°
d'enregistrement dans un tableau
- debut mesure
pour tout rec de montableau, hsupprime(monfichier, rec)
- fin mesure
pc avec 512Mo + 768Mo de swap, essai en local
Avec 2 clé (une dateheure, et un idunique):
taille fichier index 82Mo; 2 index; 0s pour hsupprimer 2000 fiches
je coche 2 champ numérique (sur 4) comme clé avec doublon :
taille fichier index 154Mo;4 index; 13s pour 2000 fiches
je coche 2 champ numérique (sur 4) comme clé avec doublon:
taille fichier index: 226 Mo: 6 index; 34s pour 2000 fiches
pour finir par un magistral:
taille fichier index: 1Go: 18 index, 200s pour 2000 fiches
d'ailleurs à ce stade, la reindexation prend environ 40minutes
ca augmente en fonction du nombre de clé, et avec le cpu qui fout rien
pendant la suppression.
je crois que je vais essayer de programmer :
copie du ORG.FIC en SAV.FIC
création d'un hdecritfichier identique à ORG.FIC mais sans les index
pour
ouverture du SAV.FIC
suppression dans le SAV
reindexation du sav
déplacement du SAV.FIC+NDX en ORG.FIC+NDX
mais j'en ai franchement raz les sacoches de perdre du temps à contourner
les problèmes d'un outil qui est censé nous en faire gagner.
"patrice" a écrit dans le message de news: 456af0b1$0$27094$
Bonjour
Soit un fichier de 600Mo, contenant environ 2.5millions de fiches, taille d'enregistrement 172 octets Une routine de suppression: chercher toutes les fiches correspondant au filtre, mettre les n° d'enregistrement dans un tableau - debut mesure pour tout rec de montableau, hsupprime(monfichier, rec) - fin mesure
pc avec 512Mo + 768Mo de swap, essai en local
Avec 2 clé (une dateheure, et un idunique): taille fichier index 82Mo; 2 index; 0s pour hsupprimer 2000 fiches je coche 2 champ numérique (sur 4) comme clé avec doublon : taille fichier index 154Mo;4 index; 13s pour 2000 fiches je coche 2 champ numérique (sur 4) comme clé avec doublon: taille fichier index: 226 Mo: 6 index; 34s pour 2000 fiches
pour finir par un magistral: taille fichier index: 1Go: 18 index, 200s pour 2000 fiches d'ailleurs à ce stade, la reindexation prend environ 40minutes
ca augmente en fonction du nombre de clé, et avec le cpu qui fout rien pendant la suppression.
je crois que je vais essayer de programmer : copie du ORG.FIC en SAV.FIC création d'un hdecritfichier identique à ORG.FIC mais sans les index pour ouverture du SAV.FIC suppression dans le SAV reindexation du sav déplacement du SAV.FIC+NDX en ORG.FIC+NDX
mais j'en ai franchement raz les sacoches de perdre du temps à contourner les problèmes d'un outil qui est censé nous en faire gagner.
VPSoft
Re-bonsoir,
Dommage d'avoir ouvert un nouveau sujet. Je viens de répondre sur le fil initial.
Vu sous cet angle, cela me parait moins "anormal". Plus il y a de clés, plus les mises à jour sont longues. C'est insignifiant lorsqu'on fait UN seul Hajoute, mais on commence à s'en apercevoir dans une série (ajoute ou supprime). Reste à voir les autres pistes que j'ai évoquées, en vrac : - Trigger après hSupprime qui fait d'autres mises à jour - Paramètre "hSecurite" trop "sécurisant" - Disque "lent" (dans mon cas, réindexation en 4 minutes chez le client, 30 chez moi sur un vieux PC qui ne sert qu'à des tests sous W2000 avec 512 Mo en ram) - X2000 serveur à optimiser - Ajouter dans un nouveau fichier les fiches à conserver puis renommer, s'il y en a plus à supprimer qu'à conserver
Bon courage,
Victor
"patrice" a écrit dans le message de news: 456af0b1$0$27094$
Bonjour
Soit un fichier de 600Mo, contenant environ 2.5millions de fiches, taille d'enregistrement 172 octets Une routine de suppression: chercher toutes les fiches correspondant au filtre, mettre les n° d'enregistrement dans un tableau - debut mesure pour tout rec de montableau, hsupprime(monfichier, rec) - fin mesure
pc avec 512Mo + 768Mo de swap, essai en local
Avec 2 clé (une dateheure, et un idunique): taille fichier index 82Mo; 2 index; 0s pour hsupprimer 2000 fiches je coche 2 champ numérique (sur 4) comme clé avec doublon : taille fichier index 154Mo;4 index; 13s pour 2000 fiches je coche 2 champ numérique (sur 4) comme clé avec doublon: taille fichier index: 226 Mo: 6 index; 34s pour 2000 fiches
pour finir par un magistral: taille fichier index: 1Go: 18 index, 200s pour 2000 fiches d'ailleurs à ce stade, la reindexation prend environ 40minutes
ca augmente en fonction du nombre de clé, et avec le cpu qui fout rien pendant la suppression.
je crois que je vais essayer de programmer : copie du ORG.FIC en SAV.FIC création d'un hdecritfichier identique à ORG.FIC mais sans les index pour ouverture du SAV.FIC suppression dans le SAV reindexation du sav déplacement du SAV.FIC+NDX en ORG.FIC+NDX
mais j'en ai franchement raz les sacoches de perdre du temps à contourner les problèmes d'un outil qui est censé nous en faire gagner.
Re-bonsoir,
Dommage d'avoir ouvert un nouveau sujet. Je viens de répondre sur le fil
initial.
Vu sous cet angle, cela me parait moins "anormal". Plus il y a de clés, plus
les mises à jour sont longues. C'est insignifiant lorsqu'on fait UN seul
Hajoute, mais on commence à s'en apercevoir dans une série (ajoute ou
supprime).
Reste à voir les autres pistes que j'ai évoquées, en vrac :
- Trigger après hSupprime qui fait d'autres mises à jour
- Paramètre "hSecurite" trop "sécurisant"
- Disque "lent" (dans mon cas, réindexation en 4 minutes chez le client, 30
chez moi sur un vieux PC qui ne sert qu'à des tests sous W2000 avec 512 Mo
en ram)
- X2000 serveur à optimiser
- Ajouter dans un nouveau fichier les fiches à conserver puis renommer, s'il
y en a plus à supprimer qu'à conserver
Bon courage,
Victor
"patrice" <patrice_labracherie_nospam@free.fr> a écrit dans le message de
news: 456af0b1$0$27094$426a34cc@news.free.fr...
Bonjour
Soit un fichier de 600Mo, contenant environ 2.5millions de fiches, taille
d'enregistrement 172 octets
Une routine de suppression:
chercher toutes les fiches correspondant au filtre, mettre les n°
d'enregistrement dans un tableau
- debut mesure
pour tout rec de montableau, hsupprime(monfichier, rec)
- fin mesure
pc avec 512Mo + 768Mo de swap, essai en local
Avec 2 clé (une dateheure, et un idunique):
taille fichier index 82Mo; 2 index; 0s pour hsupprimer 2000 fiches
je coche 2 champ numérique (sur 4) comme clé avec doublon :
taille fichier index 154Mo;4 index; 13s pour 2000 fiches
je coche 2 champ numérique (sur 4) comme clé avec doublon:
taille fichier index: 226 Mo: 6 index; 34s pour 2000 fiches
pour finir par un magistral:
taille fichier index: 1Go: 18 index, 200s pour 2000 fiches
d'ailleurs à ce stade, la reindexation prend environ 40minutes
ca augmente en fonction du nombre de clé, et avec le cpu qui fout rien
pendant la suppression.
je crois que je vais essayer de programmer :
copie du ORG.FIC en SAV.FIC
création d'un hdecritfichier identique à ORG.FIC mais sans les index
pour
ouverture du SAV.FIC
suppression dans le SAV
reindexation du sav
déplacement du SAV.FIC+NDX en ORG.FIC+NDX
mais j'en ai franchement raz les sacoches de perdre du temps à contourner
les problèmes d'un outil qui est censé nous en faire gagner.
Dommage d'avoir ouvert un nouveau sujet. Je viens de répondre sur le fil initial.
Vu sous cet angle, cela me parait moins "anormal". Plus il y a de clés, plus les mises à jour sont longues. C'est insignifiant lorsqu'on fait UN seul Hajoute, mais on commence à s'en apercevoir dans une série (ajoute ou supprime). Reste à voir les autres pistes que j'ai évoquées, en vrac : - Trigger après hSupprime qui fait d'autres mises à jour - Paramètre "hSecurite" trop "sécurisant" - Disque "lent" (dans mon cas, réindexation en 4 minutes chez le client, 30 chez moi sur un vieux PC qui ne sert qu'à des tests sous W2000 avec 512 Mo en ram) - X2000 serveur à optimiser - Ajouter dans un nouveau fichier les fiches à conserver puis renommer, s'il y en a plus à supprimer qu'à conserver
Bon courage,
Victor
"patrice" a écrit dans le message de news: 456af0b1$0$27094$
Bonjour
Soit un fichier de 600Mo, contenant environ 2.5millions de fiches, taille d'enregistrement 172 octets Une routine de suppression: chercher toutes les fiches correspondant au filtre, mettre les n° d'enregistrement dans un tableau - debut mesure pour tout rec de montableau, hsupprime(monfichier, rec) - fin mesure
pc avec 512Mo + 768Mo de swap, essai en local
Avec 2 clé (une dateheure, et un idunique): taille fichier index 82Mo; 2 index; 0s pour hsupprimer 2000 fiches je coche 2 champ numérique (sur 4) comme clé avec doublon : taille fichier index 154Mo;4 index; 13s pour 2000 fiches je coche 2 champ numérique (sur 4) comme clé avec doublon: taille fichier index: 226 Mo: 6 index; 34s pour 2000 fiches
pour finir par un magistral: taille fichier index: 1Go: 18 index, 200s pour 2000 fiches d'ailleurs à ce stade, la reindexation prend environ 40minutes
ca augmente en fonction du nombre de clé, et avec le cpu qui fout rien pendant la suppression.
je crois que je vais essayer de programmer : copie du ORG.FIC en SAV.FIC création d'un hdecritfichier identique à ORG.FIC mais sans les index pour ouverture du SAV.FIC suppression dans le SAV reindexation du sav déplacement du SAV.FIC+NDX en ORG.FIC+NDX
mais j'en ai franchement raz les sacoches de perdre du temps à contourner les problèmes d'un outil qui est censé nous en faire gagner.
patrice
"VPSoft" a écrit dans le message de news:456b54e5$0$27371$
Vu sous cet angle, cela me parait moins "anormal". Plus il y a de clés,
plus
les mises à jour sont longues. C'est insignifiant lorsqu'on fait UN seul Hajoute, mais on commence à s'en apercevoir dans une série (ajoute ou supprime).
mouais, c'est juste la croissance du délai qui m'étonne ( un fichier avec 2 index= instantané, avec 4 secondess) mais bon, merci à tous ceux qui m'ont aidé et voila la soluce finale :
(attention c'est pas un copie collé, juste l'algo)
halias(ficorg,"fictmp") hcreation("fictmp") htransactiondebut("-fictmp") - faire les totalisations éventuelles avant la purge hlitpremier(ficorg) tantque pas hendehors(ficorg) si fictmp.monchampdate>date_limite_de_purge alors hcopieenreg(fictmp,ficorg,hcopieidauto) hecrit(fictmp,hnbenr(fictmp)+1,hfixeidauto) fin hlitsuivant(ficorg) fin hreindex(fictmp) htransactionfin() //attention, ici on n'est plus couvert, faut ajouter un test au lancement du prg au cas où ca plante ici fsupprime(ficorg) fdeplacefichier(fictmp,ficorg)
"VPSoft" <vpsoft@wanadoo.fr> a écrit dans le message de
news:456b54e5$0$27371$ba4acef3@news.orange.fr...
Vu sous cet angle, cela me parait moins "anormal". Plus il y a de clés,
plus
les mises à jour sont longues. C'est insignifiant lorsqu'on fait UN seul
Hajoute, mais on commence à s'en apercevoir dans une série (ajoute ou
supprime).
mouais, c'est juste la croissance du délai qui m'étonne ( un fichier avec 2
index= instantané, avec 4 secondess)
mais bon, merci à tous ceux qui m'ont aidé et voila la soluce finale :
(attention c'est pas un copie collé, juste l'algo)
halias(ficorg,"fictmp")
hcreation("fictmp")
htransactiondebut("-fictmp")
- faire les totalisations éventuelles avant la purge
hlitpremier(ficorg)
tantque pas hendehors(ficorg)
si fictmp.monchampdate>date_limite_de_purge alors
hcopieenreg(fictmp,ficorg,hcopieidauto)
hecrit(fictmp,hnbenr(fictmp)+1,hfixeidauto)
fin
hlitsuivant(ficorg)
fin
hreindex(fictmp)
htransactionfin()
//attention, ici on n'est plus couvert, faut ajouter un test au lancement du
prg au cas où ca plante ici
fsupprime(ficorg)
fdeplacefichier(fictmp,ficorg)
"VPSoft" a écrit dans le message de news:456b54e5$0$27371$
Vu sous cet angle, cela me parait moins "anormal". Plus il y a de clés,
plus
les mises à jour sont longues. C'est insignifiant lorsqu'on fait UN seul Hajoute, mais on commence à s'en apercevoir dans une série (ajoute ou supprime).
mouais, c'est juste la croissance du délai qui m'étonne ( un fichier avec 2 index= instantané, avec 4 secondess) mais bon, merci à tous ceux qui m'ont aidé et voila la soluce finale :
(attention c'est pas un copie collé, juste l'algo)
halias(ficorg,"fictmp") hcreation("fictmp") htransactiondebut("-fictmp") - faire les totalisations éventuelles avant la purge hlitpremier(ficorg) tantque pas hendehors(ficorg) si fictmp.monchampdate>date_limite_de_purge alors hcopieenreg(fictmp,ficorg,hcopieidauto) hecrit(fictmp,hnbenr(fictmp)+1,hfixeidauto) fin hlitsuivant(ficorg) fin hreindex(fictmp) htransactionfin() //attention, ici on n'est plus couvert, faut ajouter un test au lancement du prg au cas où ca plante ici fsupprime(ficorg) fdeplacefichier(fictmp,ficorg)
Réal Phil
> halias(ficorg,"fictmp") hcreation("fictmp") htransactiondebut("-fictmp") - faire les totalisations éventuelles avant la purge hlitpremier(ficorg) tantque pas hendehors(ficorg) si fictmp.monchampdate>date_limite_de_purge alors hcopieenreg(fictmp,ficorg,hcopieidauto) hecrit(fictmp,hnbenr(fictmp)+1,hfixeidauto) fin hlitsuivant(ficorg) fin hreindex(fictmp) htransactionfin() //attention, ici on n'est plus couvert, faut ajouter un test au lancement du prg au cas où ca plante ici fsupprime(ficorg) fdeplacefichier(fictmp,ficorg)
--------------------------------------------
Intéressant, mais on est curieux de savoir: quel est le temps total final du processus avec cette méthode ?
Quelques alternatives peuvent aussi être essayés; _ POUR TOUT (au lieu du tantque) réduit le code _ Requête SQL
Si cela peut t'encourager, il y a presque toujours des situations sur chaque projet le moindrement important où il faut "ramer" dur pour optimiser les résultats.
Salutations
> halias(ficorg,"fictmp")
hcreation("fictmp")
htransactiondebut("-fictmp")
- faire les totalisations éventuelles avant la purge
hlitpremier(ficorg)
tantque pas hendehors(ficorg)
si fictmp.monchampdate>date_limite_de_purge alors
hcopieenreg(fictmp,ficorg,hcopieidauto)
hecrit(fictmp,hnbenr(fictmp)+1,hfixeidauto)
fin
hlitsuivant(ficorg)
fin
hreindex(fictmp)
htransactionfin()
//attention, ici on n'est plus couvert, faut ajouter un test au lancement du
prg au cas où ca plante ici
fsupprime(ficorg)
fdeplacefichier(fictmp,ficorg)
--------------------------------------------
Intéressant, mais on est curieux de savoir: quel est le temps total
final du processus avec cette méthode ?
Quelques alternatives peuvent aussi être essayés;
_ POUR TOUT (au lieu du tantque) réduit le code
_ Requête SQL
Si cela peut t'encourager, il y a presque toujours des situations sur
chaque projet le moindrement important où il faut "ramer" dur pour
optimiser les résultats.
> halias(ficorg,"fictmp") hcreation("fictmp") htransactiondebut("-fictmp") - faire les totalisations éventuelles avant la purge hlitpremier(ficorg) tantque pas hendehors(ficorg) si fictmp.monchampdate>date_limite_de_purge alors hcopieenreg(fictmp,ficorg,hcopieidauto) hecrit(fictmp,hnbenr(fictmp)+1,hfixeidauto) fin hlitsuivant(ficorg) fin hreindex(fictmp) htransactionfin() //attention, ici on n'est plus couvert, faut ajouter un test au lancement du prg au cas où ca plante ici fsupprime(ficorg) fdeplacefichier(fictmp,ficorg)
--------------------------------------------
Intéressant, mais on est curieux de savoir: quel est le temps total final du processus avec cette méthode ?
Quelques alternatives peuvent aussi être essayés; _ POUR TOUT (au lieu du tantque) réduit le code _ Requête SQL
Si cela peut t'encourager, il y a presque toujours des situations sur chaque projet le moindrement important où il faut "ramer" dur pour optimiser les résultats.
Salutations
patrice
"Réal Phil" a écrit dans le message de news:
Intéressant, mais on est curieux de savoir: quel est le temps total final du processus avec cette méthode ?
le temps est de l'ordre de celui de la réindexation. soit moins d'une heure pour supprimer 200Mo de fiche (contre 12h environ avec les hsupprime)
Quelques alternatives peuvent aussi être essayés; _ POUR TOUT (au lieu du tantque) réduit le code _ Requête SQL
n'a rien changé dans mon cas, ce n'est pas le code de programmation de la suppression mais le hsupprime qui rame donc la morale: avec beaucoup d'index et un gros fichier, ne pas faire de hsupprime en masse
"Réal Phil" <realmip@yahoo.ca> a écrit dans le message de
news:1164727942.431006.179600@j72g2000cwa.googlegroups.com...
Intéressant, mais on est curieux de savoir: quel est le temps total
final du processus avec cette méthode ?
le temps est de l'ordre de celui de la réindexation.
soit moins d'une heure pour supprimer 200Mo de fiche
(contre 12h environ avec les hsupprime)
Quelques alternatives peuvent aussi être essayés;
_ POUR TOUT (au lieu du tantque) réduit le code
_ Requête SQL
n'a rien changé dans mon cas, ce n'est pas le code de programmation de la
suppression mais le hsupprime qui rame
donc la morale: avec beaucoup d'index et un gros fichier, ne pas faire de
hsupprime en masse
Intéressant, mais on est curieux de savoir: quel est le temps total final du processus avec cette méthode ?
le temps est de l'ordre de celui de la réindexation. soit moins d'une heure pour supprimer 200Mo de fiche (contre 12h environ avec les hsupprime)
Quelques alternatives peuvent aussi être essayés; _ POUR TOUT (au lieu du tantque) réduit le code _ Requête SQL
n'a rien changé dans mon cas, ce n'est pas le code de programmation de la suppression mais le hsupprime qui rame donc la morale: avec beaucoup d'index et un gros fichier, ne pas faire de hsupprime en masse
Réal Phil
On 28 nov, 10:40, "patrice" wrote:
"Réal Phil" a écrit dans le message denews:1164727
>Intéressant, mais on est curieux de savoir: quel est le temps total >final du processus avec cette méthode ?le temps est de l'ordre de celu i de la réindexation. soit moins d'une heure pour supprimer 200Mo de fiche (contre 12h environ avec les hsupprime)
>Quelques alternatives peuvent aussi être essayés; >_ POUR TOUT (au lieu du tantque) réduit le code >_ Requête SQLn'a rien changé dans mon cas, ce n'est pas le code de p rogrammation de la suppression mais le hsupprime qui rame donc la morale: avec beaucoup d'index et un gros fichier, ne pas faire de hsupprime en masse
Ok mais là avec ta dernière methode tu ne fais plus de HSupprime, donc le temps doit etre bien meilleur, non?
On 28 nov, 10:40, "patrice" <patrice_labracherie_nos...@free.fr> wrote:
"Réal Phil" <real...@yahoo.ca> a écrit dans le message denews:1164727 942.431006.179600@j72g2000cwa.googlegroups.com...
>Intéressant, mais on est curieux de savoir: quel est le temps total
>final du processus avec cette méthode ?le temps est de l'ordre de celu i de la réindexation.
soit moins d'une heure pour supprimer 200Mo de fiche
(contre 12h environ avec les hsupprime)
>Quelques alternatives peuvent aussi être essayés;
>_ POUR TOUT (au lieu du tantque) réduit le code
>_ Requête SQLn'a rien changé dans mon cas, ce n'est pas le code de p rogrammation de la
suppression mais le hsupprime qui rame
donc la morale: avec beaucoup d'index et un gros fichier, ne pas faire de
hsupprime en masse
"Réal Phil" a écrit dans le message denews:1164727
>Intéressant, mais on est curieux de savoir: quel est le temps total >final du processus avec cette méthode ?le temps est de l'ordre de celu i de la réindexation. soit moins d'une heure pour supprimer 200Mo de fiche (contre 12h environ avec les hsupprime)
>Quelques alternatives peuvent aussi être essayés; >_ POUR TOUT (au lieu du tantque) réduit le code >_ Requête SQLn'a rien changé dans mon cas, ce n'est pas le code de p rogrammation de la suppression mais le hsupprime qui rame donc la morale: avec beaucoup d'index et un gros fichier, ne pas faire de hsupprime en masse
