execute statement ON EXTERNAL DATA SOURCE et performance

Bonjour tout le monde ,

j'écris une procédure stockée qui récupère des données de quelques tables depuis une base de Production

Code:

---

FOR execute statement VSQL ON EXTERNAL DATA SOURCE ...

---

il y'a 5 ou six différentes requetés dans cette procédure qui correspondent aux différentes tables .

en test local cette opération prends dans les 30 - 40 secondes.


ma question est :

y'a t'il un risque pour les autres utilisateurs connectés a la base (5 ou 6) d'être ralentis voire bloqués ?!



Merci

Cela dépend du SGBDR externe et de sa méthode de verrouillage (optimiste ou pessimiste)...

A +

et de la largeur des verrous

S'il s'agit d'une base externe Firebird, (donc une procédure qui interroge une autre BDD Firebird)

d'expérience, car j'ai ce cas de figure, mes utilisateurs (plus que 5 ou 6 ;)) n'ont rien ressenti depuis des mois (voire mes pour certaines procédures 1 ou deux ans)

effectivement , il s'agit de deux bases firebird,

sur une il y'a la procédure stockée qui interroge la base de production "externe" et remplis ces tables .

donc la table de production où est connectés tous les utilisateurs est toujours en lecture seule avec l'appel de la procédure stockée .

le truc c'est que cette opération doit se faire plusieurs fois par heure, genre 2/3 voire 4

en test localhost ça prends environ 30 a 40 secondes

j'imagine que sur le réseau local ça prends légèrement un peu plus


d'où ma question .

Citation:

---

Envoyé par SQLpro

Cela dépend du SGBDR externe et de sa méthode de verrouillage (optimiste ou pessimiste)...

A +

---

a votre avis est ce que la méthode de verrouillage peut influencer sur les performance , vu que je ne fais qu'interroger la base de production avec des requêtes select .

et en aucun cas je fais des insert, update .... etc

ps: pour le SGBD c'est firebird pour les deux installées sur le même réseau local

Citation:

---

Envoyé par Issam

effectivement , il s'agit de deux bases firebird,

---

Je m'en doutais un peu

Citation:

---

sur une il y'a la procédure stockée qui interroge la base de production "externe" et remplis ces tables .

---

C'est bien le cas de figure que je voyais

Citation:

---

donc la table de production où est connectés tous les utilisateurs est toujours en lecture seule avec l'appel de la procédure stockée .

---

Je ne comprends pas cette déduction

Citation:

---

j'imagine que sur le réseau local ça prends légèrement un peu plus

---

pourquoi ? Cela se passe sur le serveur, à moins qu'il y ait plusieurs serveurs Firebird , c'est à dire deux bases sur des postes différents

Citation:

---

Envoyé par SergioMaster

onc la table de production où est connectés tous les utilisateurs est toujours en lecture seule avec l'appel de la procédure stockée .
Je ne comprends pas cette déduction


pourquoi ? Cela se passe sur le serveur, à moins qu'il y ait plusieurs serveurs Firebird , c'est à dire deux bases sur des postes différents

---

je m'explique :

quand je fait :

Code:

---

1 2 3 4

VSQL = 'select CHNUM, CHCODE, libelle from chapitre '; FOR execute statement VSQL ON EXTERNAL DATA SOURCE Cheminbaseproduction AS USER 'sysdba' PASSWORD 'masterkey' INTO :CHNUM, :CHCODE, :libelle DO update or insert into chapitre (CHNUM, CHCODE, libelle) values (:CHNUM, :CHCODE, :libelle);

---

je fais juste un select sur la base de production , donc récupère juste les données je ne les modifie pas

Citation:

---

Envoyé par SergioMaster

pourquoi ? Cela se passe sur le serveur, à moins qu'il y ait plusieurs serveurs Firebird , c'est à dire deux bases sur des postes différents

---

oui il y'a deux postes différents chacun son propre serveur

Bonjour,

Je ne connais pas la taille de cette table "chapitre", mais ce qui me choque, c'est que vous demandiez la mise à jour de la totalité de la table à chaque interrogation. C'est peut-être ça qui prend du temps et risque de ralentir les autres utilisateurs.

André

Lorsque vous imbriquez des lectures de table pour faire des mises à jour, FireBird travaillant exclusivement en verrouillage pessimiste, des verrous de lecture sont posés sur la table lue pour empêcher d'autres utilisateur de tenter de la mettre à jour...

A +

Citation:

---

Envoyé par Issam

Code:

---

1 2 3 4

VSQL = 'select CHNUM, CHCODE, libelle from chapitre '; FOR execute statement VSQL ON EXTERNAL DATA SOURCE Cheminbaseproduction AS USER 'sysdba' PASSWORD 'masterkey' INTO :CHNUM, :CHCODE, :libelle DO update or insert into chapitre (CHNUM, CHCODE, libelle) values (:CHNUM, :CHCODE, :libelle);

---

---

par précaution j'aurai ajouté un MATCHING(CHNUM,CHCODE) pour le update or insert, cela réduira peut-être les temps

Merci pour tout :ccool: