2 questions ! [Résolu]

[lepatantpato]

Bonjour à tous

Je dois seulement lire une base firebird (et extraire des données) pour les traiter dans une application, et j'ai 2 questions:

La requête, en 1ère lecture peut durer 10 minutes ou plus; les fois suivantes, avec exactement la même requête et la même base, 8 secondes maxi...
Comment arriver à 8 secondes dès la première lecture ?

Je désire après lecture supprimer la base pour la remplacer par une autre.
Or, elle reste verrouillée, sous Windows, et donc je ne peux pas la supprimer; mais au bout d'un certain temps (environ 30 minutes il semble), je peux la supprimer. Qu'est ce qui explique cela ?

Merci !
cordialement, Lepatantpato

(pas si épatant, finalement)

[SergioMaster]

Envoyé par lepatantpato

La requête, en 1ère lecture peut durer 10 minutes ou plus; les fois suivantes, avec exactement la même requête et la même base, 8 secondes maxi...
Comment arriver à 8 secondes dès la première lecture ?

Alors là , y a comme un bug , il serait intéressant
1- d 'avoir plus de précisions (SQL , description des tables impliquées)
2- de savoir le temps de préparation (en utilisant un GUI genre Flamerobin on a les statistiques)

Je désire après lecture supprimer la base pour la remplacer par une autre.
Or, elle reste verrouillée, sous Windows, et donc je ne peux pas la supprimer; mais au bout d'un certain temps (environ 30 minutes il semble), je peux la supprimer. Qu'est ce qui explique cela ?

ça sent les transactions mal fermées ! Comment est fait la copie de la base ? ce qui d'ailleurs pourrait expliquer la question N°1

[lepatantpato]

Bonjour et merci d'avoir étudié ma question.
En fait, la base a été copiée directement sous windows.
Ce qui peut expliquer ces problèmes, sans doute.
Faut il faire une opération spécifique, par exemple avec gfix, pour fermer des transactions en cours au moment de la copie ?
j'avoue patauger, ne connaissant pas du tout firebird et ses subtilités.

cdt
Lépatantpato

[lepatantpato]

Je joins la requête, à tout hasard.
On voit que, à la suite de Where, je cherche si ETAT.NUMERO n’est pas dans le fichier FIN. J’imagine que cela prend du temps, mais je ne vois pas comment faire autrement….
LépatantPato

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
SELECT DISTINCT  
ETAT.NUMERO ,  
ETAT.PRODUIT_ID,
PFOURNISSEUR.CODE,
PRODUIT.DESIGNATION,
SORTIE.DLU,
FOURNISSEUR.NOM, 
SORTIE.DATE
 
FROM 
ETAT, 
PFOURNISSEUR,
PRODUIT, 
SORTIE, 
FOURNISSEUR
 
WHERE  
ETAT.NUMERO    NOT IN (SELECT  FIN.NUMERO     FROM  FIN)
AND ETAT.PRODUIT_ID=PRODUIT.PRODUIT_ID
AND SORTIE.NUMERO=ETAT.NUMERO
AND PFOURNISSEUR.PRODUIT_ID=PRODUIT.PRODUIT_ID
AND ETAT.FOURNISSEUR_ID= FOURNISSEUR.FOURNISSEUR_ID
AND PFOURNISSEUR.CODE IN   ('125500','789120','997788','123789');

[SergioMaster]

Envoyé par lepatantpato

En fait, la base a été copiée directement sous windows.
Ce qui peut expliquer ces problèmes, sans doute.
Faut il faire une opération spécifique

une base copiée directement peut être en cours d'utilisation et/ou des programmes mal conçus peuvent laisser des transactions ouvertes : Donc plein de problèmes possibles !
La démarche recommandée pour copier une Base est de passer par un Backup sur le poste 'émetteur' (qui en plus nettoiera la base) et un Restore sur le poste qui va recevoir la copie . ce n'est pas forcément une 'subtilité' firebird , dans un environnement réseau comment savoir si la base n'est pas en cours d'exploitation ? un backup firebird peut se fair 'à chaud' pas besoin de faire un shutdown de la base (ce qui était la règle au début d'Interbase)

Quant au SQL du post suivant , pas très normalisé tout ça (j'ai rajouté les balises de code pour la lecture)

Commençons par faire des jointures

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
SELECT DISTINCT  
ETAT.NUMERO ,  
ETAT.PRODUIT_ID,
PFOURNISSEUR.CODE,
PRODUIT.DESIGNATION,
SORTIE.DLU,
FOURNISSEUR.NOM, 
SORTIE.DATE
 
FROM  ETAT JOIN PFOURNISSEUR ON  
JOIN PRODUIT ON ETAT.PRODUIT_ID=PRODUIT.PRODUIT_ID
JOIN SORTIE ON  SORTIE.NUMERO=ETAT.NUMERO 
JOIN FOURNISSEUR ON ETAT.FOURNISSEUR_ID=FOURNISSEUR.FOURNISSEUR_ID

peut être également intervertir ce qui nous reste au niveau du WHERE

Code :

1
2
3
 
WHERE  PFOURNISSEUR.CODE IN   ('125500','789120','997788','123789')
AND ETAT.NUMERO    NOT IN (SELECT  FIN.NUMERO     FROM  FIN)

Se poser la question du DISTINCT

Vérifier avec un GUI fournissant les stats et affichant les PLANS (flamerobin par exemple )
Vérifier les jointures (ici j'ai fait le JOIN par défaut pour reproduire au plus près)

[lepatantpato]

Bonjour et merci.

Comme je ne veux pas de souci avec la base en question, car elle vient d'une autre application utilisée par environ 10 personnes tous les jours, et plutôt que de la lire directement en sql, que je ne maitrise pas (et sur laquelle je crains de créer un problème, notamment avec nbackup), j'ai pris le parti de copier cette base, et d'utiliser la copie.
Ce qui fait que la simple copie sous windows ne tient pas compte, bien entendu, de l'état de la base à ce moment-là.
Mon souci est donc de pouvoir utiliser "au mieux" la base; les informations à extraire ne sont pas primordiales et cette opération, si à un instant T, n'est pas ok, le sera un peu plus tard.
Donc;, si j'ai bien compris, il y a des transactions en cours et la base recopiée n'est pas ok. Mais pourquoi j'obtiens les bons résultats, soit en 10 minutes soit 8 secondes ? Cela signifierait que la 1ère fois, la base traitée se réorganise (par un procédé que j'ignore, évidemment) et donc met 10 minutes à répondre, et que les fois suivantes, la base étant ok, je peux la lire en 8 secondes ?
Donc ma question est : il y a t'il un programme (comme gfix ou autre) qui pourrait permettre la clôture des transactions ou autres, et permettre ensuite une lecture rapide ?
En attendant,
merci d'avoir pris le temps de me lire
cdt
Lépatantpato

par ailleurs, je vais étudier votre code sql; cela commence à m'intéresser (je développe principalement en Windev)

[SergioMaster]

Oui , Gfix fera 'la même chose' après la copie de la base
mais un backup ne te posera aucun soucis sur la base d'exploitation

Envoyé par Expérience

J'ai mis en place un système régulier horaire (cron ou wintask) de Backup sur une base en exploitation sans aucune pénalité visible .
J'ai fait cela il y a des années sur une Base IB 5.2 au départ cette dernière était utilisé sur un réseau plus que capricieux , et un serveur qui on l'a découvert beaucoup plus tard un processeur erratique (surchauffe) . Avant au minimum 2 arrêts maintenance de la Base par semaine , après 1 par mois et encore pour contrôle.
Depuis j'ai pris l'habitude de mettre en place un backup régulier hors heure de travail pour externaliser une sauvegarde régulière de la BDD
pas de nBackup , un simple GBAK

un Gfix marque les enregistrements et problèmes (options -m) et peut faire un nettoyage mais :
Généralement après un Gfix , on fait un backup/restore pour avoir une BDD propre donc .....

la base traitée se réorganise (par un procédé que j'ignore, évidemment)

il doit s'agir d'un 'sweep' de la base (une opération programmée, automatique de nettoyage) : à vérifier

un Backup fait un sweep donc ....

[lepatantpato]

Bonjour
En fait, gfix appelé après copie et avant traitement résout le problème. Mais le traitement dure plusieurs minutes.
Par ailleurs, j’ai 2 mêmes bases copiées à quelques jours d’écart. J’accède à la 1ère en quelques secondes, et à la seconde en plusieurs minutes. Cela rejoint donc le fait que, lors des copies, les bases sont dans un état utilisable ou non selon.
Mais en lisant tes réponses, je me dis que j’aurais intérêt à interroger en sql directement la base, sans même passer par gbak ou nbackup…comme je dois uniquement extraire des infos (et non écrire). En réalité, je crains (sûrement à tort) de poser des problèmes sur cette base, qui est en fonctionnement permanent (sauf la nuit, mais du coup sans intérêt).
A ton avis, puis-je interroger cette base sans précautions particulières ?

Merci encore.
Lépatantpato

[Barbibulle]

Une copie d'un fichier ouvert / en utilisation est une très mauvaise idée et ca ce n'est pas spécifique à firebird ....

Cela pourrait endommager la source (certain outils de copie ouvre la source en exclusif empêchant firebird de terminer le travail en cours).

Utilisez les outils de la base de données pour travailler soit directement en SQL soit sur une sauvegarde que vous aurez faite avec Backup / restore.

8/10 minutes pour une simple requête à 4 jointures ?? A moins de ramener des millions de lignes, il y a un soucis dans la requête ou de conception de la base (notamment des clés étrangères / clés primaire / index).

[lepatantpato]

Bonjour
et merci à vous deux de vos réponses.
J'ai bien avancé, et finalement, je vais questionner la base de données firebird. Cela permettra d'aller plus vite (en fait j'ai bien mes 8 secondes et non plus 10 minutes). la seule chose qui m'interpelle encore est celle ci:
puis lire dans la base et extraire des données sans tenir compte (d'ailleurs je ne vois pas comment) de l'état en cours de la base.
Je m'explique; dans d'autres langages, il faut passer par un mode de verrouillage/déverrouillage; avec Firebird, puis je extraire des données sans être bloqué, ou sans bloquer la base ?
Encore merci
LépatantPato

[SergioMaster]

Envoyé par lepatantpato

Dans d'autres langages, il faut passer par un mode de verrouillage/déverrouillage

Là on ne parle pas vraiment de 'langage'

avec Firebird, puis je extraire des données sans être bloqué, ou sans bloquer la base ?

OUI , heureusement

Verrouillage/déverrouillage d'enregistrements est une vieille notion de avant les SGBD relationnelles (années 80-90 je dirais , mes premières années informatiques ça date) .
Les SGBD 'parlent' plutôt de transactions . Je suggère de faire un tour du coté des tutoriels et articles généraux (pas spécialement Firebird) pour comprendre exactement tout ce que cela englobe .
(perso , ayant été formé dans ces fameuses années 80 , je n'en maitrise pas tout les aspects, et mes explications ne serait certainement pas exactes, ou pour le moins sujettes a de grosses controverses)
suggestion de lecture http://sqlpro.developpez.com/cours/sqlaz/techniques/#L1

[lepatantpato]

Bonjour à tous
je compte utiliser un script avec isql.
Ce script sert uniquement à extraire des données.
Dois-je le terminer avec
rien
ou
commit;
ou
commit;
quit;

Cela fonctionne dans les 3 cas. Mais la base que j'utilise en exemple est une simple copie, et non celle en fonctionnement réel.

Merci
LépatantPato

[SergioMaster]

Rien , puisque ce n'est que des extractions .
Enfin sauf le quit; pour sortir de ISQL

[lepatantpato]

Bonjour
Merci de vos conseils à vous deux.
je vais travailler ma requête en utilisant Inner join.
A bientôt, peut être !

LépatantPato

[lepatantpato]

Rebonjour
Juste une question (!)
Avec gstat, j'interroge la copie de la base et gstat m'indique qu'elle a été faite en version 1.5 (ODS 10.1).
Bon. J'utilise Firebird 2.5 et je lis sans problèmes la base. (je suppose que le contraire ne serait pas possible).
Quand je vais interroger la vrai base, en activité, cela peut il poser un problème si elle est utilisée avec Firebird 1.5, pendant que moi je vais la lire en 2.5 ?
Ou bien faut il que j'utilise également Firebird 1.5 ?
et je suppose une version ISQL de même version ?
cordialement
et bravo pour votre patience
LépatantPato

[SergioMaster]

Bien que n'ayant jamais fait ce genre de tentatives (en général je upgrade en même temps) je répondrais "qu'il n'y a aucun problème"
Sauf au niveau des fonctionnalités (les nouvelles de 2.1 à 2.5)

Si j'ai bien compris tu vas te connecter à la base réseau (soit celle hébergée sur un 'serveur de données' soit une base poste à poste)
la seule chose vraiment utile est d'ouvrir le port 3050 sur le(s) poste(s) .
En fait , tu ne vas pas utiliser le serveur (service) Firebird de ton poste mais uniquement le client (fbclient.dll ou gds32.dll) .

Une question me trotte a l'esprit depuis ma réponse d'hier
Es-tu tellement attaché aux outils en console de commande fourni par Firebird que tu ne veux pas passer par un GUI ?
(je pense a flamerobin mon préféré : pas gros, Windows et Linux, et Free ce qui ne gache rien . Ce dernier me permet même de proposer des reports rapides )

[Barbibulle]

Envoyé par SergioMaster

Rien , puisque ce n'est que des extractions .
Enfin sauf le quit; pour sortir de ISQL

Il est toujours préférable de faire soit même ce qui doit être fait.
Donc faites un commit (c'est préférable qu'un rollback plus couteux en gestion pour firebird même si vous n'avez fait que des selects).

C'est vrai que pas mal d'outil ferment automatiquement les transactions ouvertes quand on le quitte mais si vous le faites vous même vous en serez certain (d'avoir fermé correctement la transaction).

Quand à la transaction en elle même par défaut vous serez en snapshot c'est le niveau d'isolement le plus haut mais le plus couteux en resource, le read_commited en lecture seule ("read_committed", "read", "rec_version" et "no wait") est en générale bien suffisant pour du reporting (le paramètre "read" rend la transaction en lecture seule (toute tentative de modification directe (par update/delete/insert) ou indirecte (par exemple on fait un select d'une procédure qui en plus de renvoyer des données fait des updates ou autres modifications dans la base) sera soldé par un message d'erreur).

[lepatantpato]

Bonjour
En fait, je ne suis pas attaché plus que ça à utilise ISQL ou autre. Je dois extraire des données d’une base d’une application de mon client.
Donc, je procède (par programmation) ainsi :
- création d’un script LIRE.SQL contenant :
o select …
o Etc…
o where produits.ref in ici, liste de valeurs à chercher, issues de mon application (valeurs variables)
- appel d’un fichier batch contenant :
o ISQL – u sysdba – password masterkey mabase.fdb –i lire.sql –o resultats.txt
- Et enfin lecture et traitement par mon application du fichier resultats.txt

Comme tout cela fonctionne (en mode test) , cela me convient.
Bien sûr, je sais qu’il me faut améliorer certaines choses, mon script par exemple ; j’obtiens un résultat en 8 secondes mais peut-être pourrais-je abaisser cette durée.
Est-ce que Flamerobin est vraiment utile pour moi, dans ce cas précis ? je ne sais pas, à vrai dire, puisque je ne le connais pas.
Cordialement
Lépatantpato

[SergioMaster]

non , dans ce contexte , pas la peine de GUI c'est clair

[makowski]

Envoyé par SergioMaster

Rien , puisque ce n'est que des extractions .
Enfin sauf le quit; pour sortir de ISQL

pardon ?
avec isql exit fait un commit avant de sortit, quit fait un rollback
donc exit, pas quit

Code :

1
2
EXIT                       -- exit and commit changes
QUIT                       -- exit and roll back changes

et même pour des select, finir par un commit, c'est mieux, cela ferme la transaction