Discussion :

[darinze]

Bonjour,

J'ai un curseur sur une table de la base, qui retourne 210 enregistrements.
Je dois écrire un fichier XML à partir de ces enregistrements : pour chacun d'eux, les valeurs à écrire dans le XML sont tirées de la base, et une dernière doit être lue dans un fichier texte, par ailleurs parfaitement accessible au SGBD (directory déclaré avec les droits kivonbien).
A chaque passe du curseur, ce fichier texte est ouvert, lu, et refermé.
Le seul qui reste constamment ouvert est donc le fichier XML en cours d'écriture.

Ce qu'il se passe : systématiquement à partir du seizième élément et au-delà, le SGBDR refuse obstinément d'ouvrir les fichiers textes...
Obstinément signifie : le 16° fichier existe, comme les 15 précédents (qui ont tous été lus sans aucun problème) et absolument tous les suivants, il est non vide, il est situé au même endroit, dispose des même droits rw-rw-rw et appartient au même propriétaire.
J'ai rusé pour limiter les enregistrements renvoyés par le curseur au 15 et 16° de la liste initiale: ouverture sans aucun souci du fichier 16 qui avait été refusé à la passe précédente, donc, il n'y a pas de problème inhérent au fichier lui-même.
J'ai re-rusé pour renvoyer une autre liste que la liste initiale: "ouverture impossible" à partir systématiquement du 16° fichier ouvert. Quels que soient les enregistrements renvoyés par le curseur, le SGBD refuse toute ouverture à partir du 16° fichier, et tous les autres.
J'ai tenté un FFLUSH du fichier XML en écriture à chaque passe. Aucun effet.

Y a-t-il une limite par défaut au nombre de fichier ouverts ?
Je rappelle que ce ne sont pas des ouvertures concurrentes puisque chaque fichier est supposé être ouvert, lu, et refermé avant de passer au suivant.

Merci pour votre aide.

[darinze]

c'est passé à 49 fichiers ouverts sans souci, tous les autres en erreur au delà du 50°.
Et je n'ai aucune idée pourquoi.

Enfin, le problème reste le même même si le nombre varie.

[al1_24]

Tes fichiers sont lourds ?
Est-ce que ça ne vaudrait pas la peine de les charger en CLOB dans une table de travail pour y accéder en une seule passe ?

[darinze]

Merci pour vos réponses.

Les fichiers texte à lire ne sont pas lourds : c'est du code HTML, le plus gros doit faire 8Ko.

A chaque passe du curseur:
1. check si le fichier texte existe avec UTL_FILE.FOPEN() . Si exception (= fichier inexistant ou non accessible) on ne traite pas l'enregistrement.
2. écriture dans le fichier de sortie de quelques infos issues du curseur
3. lecture du contenu du fichier ouvert en (1), ré-écriture de ce contenu dans le fichier de sortie, fermeture du fichier

Voici un extrait du log aux alentours du plantage:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
        ORDRE=162494 COMMANDE=237412
        . ok pour le texte : /home/xmd/batch/int_legales/work/162494.html
        . ouverture de la balise ANNONCE
        . lecture du texte
        . html lu et ?crit
        . lecture du client = 080628-EP MAIRIE PERPIGNAN, POLE HABITAT INDIGNE
        . lecture des criteres
        ORDRE=162495 COMMANDE=237413
        . ok pour le texte : /home/xmd/batch/int_legales/work/162495.html
        . ouverture de la balise ANNONCE
        . lecture du texte
        . html lu et ?crit
        . lecture du client = 080628-EP MAIRIE PERPIGNAN, POLE HABITAT INDIGNE
        . lecture des criteres
        ORDRE=162504 COMMANDE=237508
        . ouverture impossible du fichier html : /home/xmd/batch/int_legales/work/162504.html, erreur #-29283-ORA-29283: invalid file operation
        ORA-06512: at "SYS.UTL_FILE", line 536
        ORA-29283: invalid file operation
        ORDRE=162506 COMMANDE=237510
        . ouverture impossible du fichier html : /home/xmd/batch/int_legales/work/162506.html, erreur #-29283-ORA-29283: invalid file operation
        ORA-06512: at "SYS.UTL_FILE", line 536
        ORA-29283: invalid file operation
        ORDRE=162526 COMMANDE=237566
        . ouverture impossible du fichier html : /home/xmd/batch/int_legales/work/162526.html, erreur #-29283-ORA-29283: invalid file operation
        ORA-06512: at "SYS.UTL_FILE", line 536
        ORA-29283: invalid file operation
        ORDRE=162527 COMMANDE=237567
        . ouverture impossible du fichier html : /home/xmd/batch/int_legales/work/162527.html, erreur #-29283-ORA-29283: invalid file operation
        ORA-06512: at "SYS.UTL_FILE", line 536
        ORA-29283: invalid file operation
        ORDRE=162531 COMMANDE=237657
        . ouverture impossible du fichier html : /home/xmd/batch/int_legales/work/162531.html, erreur #-29283-ORA-29283: invalid file operation
        ORA-06512: at "SYS.UTL_FILE", line 536
        ORA-29283: invalid file operation
        ORDRE=162570 COMMANDE=237806
...

. Lorsque la mention "ok pour le texte" apparaît c'est que le FOPEN() cité en (1) a été passé, donc que le fichier correspondant a été ouvert et peut être lu
. Lorsque la mention "html lu et ?crit" apparaît c'est qu'on a passé l'instruction FCLOSE() qui ferme le fichier texte ouvert en (1)
. à partir de l'enregistrement " ORDRE=162504 COMMANDE=237508" on remarque que tous les FOPEN en (1) échouent systématiquement. Pourtant, les fichiers correspondants (par exemple /home/xmd/batch/int_legales/work/162504.html) sont parfaitement réguliers, accessibles, non vides.
. Si je truque mon curseur pour lui faire renvoyer uniquement 2 enregistrements: l'ordre 162495 (qui a fonctionné dans le log ci-dessus) et le 162504 (qui a échoué), les 2 fonctionnent très bien. Donc il n'y a pas en soi, de problème inhérent au fichier 162504.html
. Si je truque autrement mon curseur pour décaler l'ensemble résultat, au final ça merde toujours au 50° fichier, quel que soit le numéro en cours, et évidemment indépendamment du fichier html qui est toujours accessible, non vide, et totalement régulier (pas un lien, pas dans un répertoire NFS monté, etc...)
==> bref c'est bien le 50° fichier à ouvrir (et tous les suivants) qui échoue, quelque soit le nom qu'il porte à ce moment-là.

Voilà.
Le user UNIX (oracle) a un ulimit -n à 65537.
Un getfacl sur les fichiers qui échouent montrent des droits tout à fait corrects (rw-rw-rw-)

Je ne sais que faire à part saucissoner mon curseur en tranches de 49 pour pouvoir passer le truc en x fois. Quelle misère.

[darinze]

(ps) hier en postant mon premier message j'ai écrit que l'ouverture des fichiers échouait à partir du 16°. C'était vrai au moment où je l'ai écrit.

Il se trouve que dans l'après midi (et je ne sais absolument pas pourquoi), ça s'est mis à merder à partir du 50°.
C'est toujours le cas ce matin.

[darinze]

Oui alors s'il vous plaît, mettez-vous à plusieurs et commencez la distribution de baffes.
J'sus dispo.

Confondre un DBMS_OUTPUT.PUT_LINE() avec un FCLOSE() et assurer ainsi qu'on a bien fermé chaque fois le fichier ouvert, alors qu'en fait on écrit juste une ligne dans le log, je crois que je ne l'avais jamais osé. Heureusement que le ridicule ne tue pas et que j'ai un pseudo et que personne ne sait où je travaille.

Donc maintenant que effectivement je ferme réellement le fichier html ouvert, tout va bien jusqu'au bout.

Désolé d'avoir usé de votre temps pour rien, skuatamad et al1_24...
( ... al1_24 ? le même que là-bas ? putèze, je comprends maintenant )

et merci pour votre aide
cet idiot sujet avec son idiot non-problème est donc résolu, fermé, et à foutre au feu.

[skuatamad]

Il nous faudrait à minima le message d'erreur, ensuite peut être le code de la procédure et la façon dont elle est appelée.
Le chiffre 16, la comme çà sans aucune info, me fait penser à l'arraysize de sqlplus défini par défaut à 15, mais comme on a aucune info tangible, ce n'est que pur spéculation...