Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement WinDev Oracle 8i, 70'000 lignes, 3h de traitement !!

Oracle 8i, 70'000 lignes, 3h de traitement !!

7 réponses
Avatar
Yves T
Bonjour,
C'est la 1ère fois que je traite une base Orable .. sans accès natif !
Cependant, je trouve tout de même incroyable qu'il me faut 3h sur un
serveur Oracle 8, 1Go RAM, P4 3Ghz pour executer ce code :

ClientSafirHF est une base HF
Req_Factures est basé sur un fichier Oracle

HLitPremier(ClientsSafirHF,DRELNUM)
TANTQUE PAS HEnDehors(ClientsSafirHF)

HExécuteRequête(Req_Factures,hRequêteDéfaut,Annee,ClientsSafirHF.DRELNUM)
//si HNbEnr(Req_Factures,hEtatTous) > 0 alors
HLitPremier(Req_Factures)
SI HEnDehors(Req_Factures) = Vrai ALORS
ClientsSafirHF.ClientActif = Faux
SINON
ClientsSafirHF.ClientActif = Vrai
FIN

HModifie(ClientsSafirHF)
HLitSuivant(ClientsSafirHF)
FIN

Est-ce que quelqu'un a une proposition à me faire ??

Merci
Yves
Signaler un problème avec ce contenu

7 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Emmanuel Lecoester
"Yves T" a écrit dans le message de
news:42ea4704$
Bonjour,
C'est la 1ère fois que je traite une base Orable .. sans accès natif !
Cependant, je trouve tout de même incroyable qu'il me faut 3h sur un
serveur Oracle 8, 1Go RAM, P4 3Ghz pour executer ce code :



8.0.6 ou 8.1.7 ?

ClientSafirHF est une base HF
Req_Factures est basé sur un fichier Oracle

HLitPremier(ClientsSafirHF,DRELNUM)
TANTQUE PAS HEnDehors(ClientsSafirHF)

HExécuteRequête(Req_Factures,hRequêteDéfaut,Annee,ClientsSafirHF.DRELNUM)
//si HNbEnr(Req_Factures,hEtatTous) > 0 alors
HLitPremier(Req_Factures)
SI HEnDehors(Req_Factures) = Vrai ALORS
ClientsSafirHF.ClientActif = Faux
SINON
ClientsSafirHF.ClientActif = Vrai
FIN

HModifie(ClientsSafirHF)
HLitSuivant(ClientsSafirHF)
FIN

Est-ce que quelqu'un a une proposition à me faire ??



oui si tu nous donnes la requete de select sur les Factures :-) ainsi que le
plan associé (si tu ne l'as pas les indexes) les stat oracle aussi ce serait
bien

en première kecture je dirais qu'il te manque un index sur la colonne de la
table factures qui utilise DRELNUM.

Merci
Yves


Avatar
Yves T
Debians wrote:
Yves T avait énoncé :

Bonjour,
C'est la 1ère fois que je traite une base Orable .. sans accès natif !
Cependant, je trouve tout de même incroyable qu'il me faut 3h sur un
serveur Oracle 8, 1Go RAM, P4 3Ghz pour executer ce code :

ClientSafirHF est une base HF
Req_Factures est basé sur un fichier Oracle

HLitPremier(ClientsSafirHF,DRELNUM)
TANTQUE PAS HEnDehors(ClientsSafirHF)

HExécuteRequête(Req_Factures,hRequêteDéfaut,Annee,ClientsSafirHF.DRELNUM)

//si HNbEnr(Req_Factures,hEtatTous) > 0 alors
HLitPremier(Req_Factures)
SI HEnDehors(Req_Factures) = Vrai ALORS
ClientsSafirHF.ClientActif = Faux
SINON
ClientsSafirHF.ClientActif = Vrai
FIN

HModifie(ClientsSafirHF)
HLitSuivant(ClientsSafirHF)
FIN

Est-ce que quelqu'un a une proposition à me faire ??




Déjà là je vois 2 tables parcourues.
70000 lignes c'est ton produit cartésien?
Combien de clients?
Si t'as 70000 clients, ca fait 70000 requetes...;)
Et quoi comme accès non natif?

OLE DB? ODBC? ODBC Microsoft ou Oracle?

Tu ne donnes pas non plus le contenu de REQ_Factures.





C'est Oracle 8.1.7
J'ai bien 70'000 clients
Ca fait bien 70'000 requêtes puisque j'attaque une base qui est celle
d'un ERP pour rapatrier des données dans une base HF afin d'ajouter des
fonctonnalités via Windev.

L'accès est OLE DB.

Ma requete est :

SELECT DFAJ.DFAJSOC AS DFAJSOC,DFAJ.DFAJEXE AS DFAJEXE,DFAJ.DFAJCOD AS
DFAJCOD,DFAJ.DFAJFAC AS DFAJFAC,DFAJ.DFAJNUM AS DFAJNUM,DFAJ.DFAJDAT AS
DFAJDAT FROM DFAJ WHERE DFAJ.DFAJEXE > Param_Annee AND DFAJ.DFAJNUM =
Param_Relation

Effectivement, DRELNUM n'est pas clé dans DFAJ (Factures) !!
Une clé composée existe sur DFAJSOC+DFAJNUM. Mais la rubrique DFAJSOC
n'existe pas dans CLIENT.
Ce qui n'est pas évident, c'est que j'ai pas de descriptif de cette base
Oracle.
Avatar
Ph. B.
Yves T a écrit:

Debians wrote:

Yves T avait énoncé :

Bonjour,
C'est la 1ère fois que je traite une base Orable .. sans accès natif !
Cependant, je trouve tout de même incroyable qu'il me faut 3h sur un
serveur Oracle 8, 1Go RAM, P4 3Ghz pour executer ce code :

ClientSafirHF est une base HF
Req_Factures est basé sur un fichier Oracle

HLitPremier(ClientsSafirHF,DRELNUM)
TANTQUE PAS HEnDehors(ClientsSafirHF)


HExécuteRequête(Req_Factures,hRequêteDéfaut,Annee,ClientsSafirHF.DRELNUM)

//si HNbEnr(Req_Factures,hEtatTous) > 0 alors
HLitPremier(Req_Factures)
SI HEnDehors(Req_Factures) = Vrai ALORS
ClientsSafirHF.ClientActif = Faux
SINON
ClientsSafirHF.ClientActif = Vrai
FIN

HModifie(ClientsSafirHF)
HLitSuivant(ClientsSafirHF)
FIN

Est-ce que quelqu'un a une proposition à me faire ??





Déjà là je vois 2 tables parcourues.
70000 lignes c'est ton produit cartésien?
Combien de clients?
Si t'as 70000 clients, ca fait 70000 requetes...;)
Et quoi comme accès non natif?

OLE DB? ODBC? ODBC Microsoft ou Oracle?

Tu ne donnes pas non plus le contenu de REQ_Factures.





C'est Oracle 8.1.7
J'ai bien 70'000 clients
Ca fait bien 70'000 requêtes puisque j'attaque une base qui est celle
d'un ERP pour rapatrier des données dans une base HF afin d'ajouter des
fonctonnalités via Windev.

L'accès est OLE DB.

Ma requete est :

SELECT DFAJ.DFAJSOC AS DFAJSOC,DFAJ.DFAJEXE AS DFAJEXE,DFAJ.DFAJCOD AS
DFAJCOD,DFAJ.DFAJFAC AS DFAJFAC,DFAJ.DFAJNUM AS DFAJNUM,DFAJ.DFAJDAT AS
DFAJDAT FROM DFAJ WHERE DFAJ.DFAJEXE > Param_Annee AND DFAJ.DFAJNUM =
Param_Relation

Effectivement, DRELNUM n'est pas clé dans DFAJ (Factures) !!
Une clé composée existe sur DFAJSOC+DFAJNUM. Mais la rubrique DFAJSOC
n'existe pas dans CLIENT.
Ce qui n'est pas évident, c'est que j'ai pas de descriptif de cette base
Oracle.



Bonjour,

Compte tenu de la requête, écris la dèjà de manière plus concise
(suppression des préfixes et alias inutiles):

SELECT DFAJSOC, DFAJEXE, DFAJCOD, DFAJFAC, DFAJNUM, DFAJDAT FROM DFAJ
WHERE DFAJEXE > Param_Annee AND DFAJNUM = Param_Relation

Tu économises un peu plus de 100 car pour ta requête, soit un échange
réduit de plus de 7 000 000 octets....
--
Philippe.
Avatar
Emmanuel Lecoester
"Ph. B." a écrit dans le message de
news:42ecaf93$0$6052$
Yves T a écrit:

> Debians wrote:
>
>> Yves T avait énoncé :
>>
>>> Bonjour,
>>> C'est la 1ère fois que je traite une base Orable .. sans accès natif !



essaie un accès natif (le mien si possible :-)) tu auras au moins la
fonction "reuse cursor" en plus.

>>> Cependant, je trouve tout de même incroyable qu'il me faut 3h sur un
>>> serveur Oracle 8, 1Go RAM, P4 3Ghz pour executer ce code :



[CUT]

> C'est Oracle 8.1.7
> J'ai bien 70'000 clients
> Ca fait bien 70'000 requêtes puisque j'attaque une base qui est celle
> d'un ERP pour rapatrier des données dans une base HF afin d'ajouter des
> fonctonnalités via Windev.
>
> L'accès est OLE DB.
>
> Ma requete est :
>
> SELECT DFAJ.DFAJSOC AS DFAJSOC,DFAJ.DFAJEXE AS DFAJEXE,DFAJ.DFAJCOD AS
> DFAJCOD,DFAJ.DFAJFAC AS DFAJFAC,DFAJ.DFAJNUM AS DFAJNUM,DFAJ.DFAJDAT AS
> DFAJDAT FROM DFAJ WHERE DFAJ.DFAJEXE > Param_Annee AND DFAJ.DFAJNUM > > Param_Relation



Compte tenu de la requête, écris la dèjà de manière plus concise
(suppression des préfixes et alias inutiles):

SELECT DFAJSOC, DFAJEXE, DFAJCOD, DFAJFAC, DFAJNUM, DFAJDAT FROM DFAJ
WHERE DFAJEXE > Param_Annee AND DFAJNUM = Param_Relation



C'est vrai que çà se lit un peu mieux comme celà :-)

Tu économises un peu plus de 100 car pour ta requête, soit un échange
réduit de plus de 7 000 000 octets....



C'est vrai aussi mais çà ne prend pas 3 heures :-)

> Effectivement, DRELNUM n'est pas clé dans DFAJ (Factures) !!
> Une clé composée existe sur DFAJSOC+DFAJNUM. Mais la rubrique DFAJSOC
> n'existe pas dans CLIENT.



C'est l'inconvénient de gérer des clés composées au lieu d'indexes non
uniques. C'est la même chose mais les développeurs WinDev pensent souvent
que les 2 colonnes sont indexées. Pour Oracle c'est bien d'abord DFAJSOC
puis DFAJNUM qui est indexée.

> Ce qui n'est pas évident, c'est que j'ai pas de descriptif de cette base
> Oracle.



En soit ce n'est pas trop le problème. Le problème serait si tu ne peux pas
modifier la base. Car dans ton cas c'est très simple il suffit de créer un
index sur DFAJNUM (voir avec ton dba si un index bitmap est adapté en
fonction de la cardinalité de cette colonne). Si la cardinalité DFAJSOC est
importante (> 100 pour chaque DFAJNUM), un index sur DFAJNUM, DFAJSOC serait
peut-etre plus adapté. Ne pas oublier de faire un compute statistics après
bien sur :-)

Si tu ne peux pas modifier la base de données désolé ta requete fera
toujours un "ACCESS FULL" sur la table (ce qui veut dire aussi que les temps
de réponses augmenteront avec ta volumétrie dans le temps!).

Sinon pour optimiser ton traitement au lieu de parcourir tes clients (HF)
puis tes factures (Oracle), tu fais le contraire... Pour toutes tes factures
lues, tu modifies le client si besoin est. Tu n'auras qu'un seul ACCESS FULL
en base soit un fetch total des factures en 15 secondes :-)

--
Emmanuel Lecoester
www.sqlmanagerx.com
Avatar
Roumegou Eric
Emmanuel Lecoester avait soumis l'idée :
"Ph. B." a écrit dans le message de
news:42ecaf93$0$6052$
Yves T a écrit:

Debians wrote:

Yves T avait énoncé :

Bonjour,
C'est la 1ère fois que je traite une base Orable .. sans accès natif !









essaie un accès natif (le mien si possible :-)) tu auras au moins la
fonction "reuse cursor" en plus.

Cependant, je trouve tout de même incroyable qu'il me faut 3h sur un
serveur Oracle 8, 1Go RAM, P4 3Ghz pour executer ce code :









[CUT]

C'est Oracle 8.1.7
J'ai bien 70'000 clients
Ca fait bien 70'000 requêtes puisque j'attaque une base qui est celle
d'un ERP pour rapatrier des données dans une base HF afin d'ajouter des
fonctonnalités via Windev.

L'accès est OLE DB.

Ma requete est :

SELECT DFAJ.DFAJSOC AS DFAJSOC,DFAJ.DFAJEXE AS DFAJEXE,DFAJ.DFAJCOD AS
DFAJCOD,DFAJ.DFAJFAC AS DFAJFAC,DFAJ.DFAJNUM AS DFAJNUM,DFAJ.DFAJDAT AS
DFAJDAT FROM DFAJ WHERE DFAJ.DFAJEXE > Param_Annee AND DFAJ.DFAJNUM >>> Param_Relation





Compte tenu de la requête, écris la dèjà de manière plus concise
(suppression des préfixes et alias inutiles):

SELECT DFAJSOC, DFAJEXE, DFAJCOD, DFAJFAC, DFAJNUM, DFAJDAT FROM DFAJ
WHERE DFAJEXE > Param_Annee AND DFAJNUM = Param_Relation



C'est vrai que çà se lit un peu mieux comme celà :-)


les prefixes tables devant la colonne à supprimer quand la table est
unique dans la requête, oui. Mais quand il y a plusieurs tables, je les
met systématiquement. Pour les AS à part des zones calculées, quand on
a une convention de nommage de colonne qui tient la route, pourquoi
renommer les zones ?

Tu économises un peu plus de 100 car pour ta requête, soit un échange
réduit de plus de 7 000 000 octets....





Pour moi le problème est pourquoi 7OOOO requetes ?
Pas vraiment plongé dans le truc, mais à première vue j'extrairais
toutes les factures dans une requetes et travaillerait ensuite en
rupture pour mettre ma table HF à jour.

En vrai si cela ne tenait qu'à moi, je travaillerais aussi en oracle
sur les tables clients au lieu d'HF pour travailler en jointure mais là
je suis HS :')


C'est vrai aussi mais çà ne prend pas 3 heures :-)

Effectivement, DRELNUM n'est pas clé dans DFAJ (Factures) !!
Une clé composée existe sur DFAJSOC+DFAJNUM.






Berk! berk ! berk! les clés composées.
Mais la rubrique DFAJSOC
n'existe pas dans CLIENT.





C'est l'inconvénient de gérer des clés composées au lieu d'indexes non
uniques.



On est d'accord Manu
C'est la même chose mais les développeurs WinDev pensent souvent
que les 2 colonnes sont indexées. Pour Oracle c'est bien d'abord DFAJSOC
puis DFAJNUM qui est indexée.

Ce qui n'est pas évident, c'est que j'ai pas de descriptif de cette base
Oracle.






Si tu as accès au dictionnaire Oracle, tu es le roi du pétrole.

En soit ce n'est pas trop le problème. Le problème serait si tu ne peux pas
modifier la base. Car dans ton cas c'est très simple il suffit de créer un
index sur DFAJNUM (voir avec ton dba si un index bitmap est adapté en
fonction de la cardinalité de cette colonne). Si la cardinalité DFAJSOC est
importante (> 100 pour chaque DFAJNUM), un index sur DFAJNUM, DFAJSOC serait
peut-etre plus adapté. Ne pas oublier de faire un compute statistics après
bien sur :-)

Si tu ne peux pas modifier la base de données désolé ta requete fera
toujours un "ACCESS FULL" sur la table (ce qui veut dire aussi que les temps
de réponses augmenteront avec ta volumétrie dans le temps!).

Sinon pour optimiser ton traitement au lieu de parcourir tes clients (HF)
puis tes factures (Oracle), tu fais le contraire... Pour toutes tes factures
lues, tu modifies le client si besoin est. Tu n'auras qu'un seul ACCESS FULL
en base soit un fetch total des factures en 15 secondes :-)



Il est fort le manu non ;-)

--
Eric Roumégou
http://cerbermail.com/?TSoulBerPA
(cliquez sur le lien ci-dessus pour me contacter en privé)
Avatar
Yves T
Merci à tous pour vos remarques et infos ... je suis passé à moins de 15
minutes !!

Bonne soirée
Yves
Avatar
Manu
"Yves T" wrote in message
news:42eebdfc$
Merci à tous pour vos remarques et infos ... je suis passé à moins de 15
minutes !!



En faisant quoi ? la création d'index ou la revue de l'algo ?

Bonne soirée
Yves