Discussion :

[djseb182]

Bonjour,

Je me pose des questions sur un problème que j'ai rencontré en voulant importer le contenu d'un fichier excel dans une de mes bases de données.

J'execute pour cela un petit bout de code T-SQL qui ressemble à cela :

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
 
SELECT * 
INTO #myExcelData
FROM OPENROWSET (      
  'Microsoft.ACE.OLEDB.12.0',
  'Excel 8.0;Database=c:\Fichier.xls;HDR=YES;IMEX=1', 
  'SELECT Civilité,Nom,Prénom,Fonction,Organisme,Adresse1,Adresse2,CP,Ville,Téléphone,Fax,Email FROM [Export$]'
)
 
declare row_cursor cursor for select Civilité,Nom,Prénom,Fonction,Organisme,Adresse1,Adresse2,CP,Ville,Téléphone,Fax,Email from #myExcelData
 
open row_cursor 
fetch next from row_cursor into @ADRCONTACTINTITULE,@ADRCONTACTNOM,@ADRCONTACTPRENOM,@ADRCONTACTFONCTION,@ORGANISME,@ADR1,@ADR2,@ADRCP,@ADRVILLE,@ADRTEL,@ADRFAX,@ADRMAIL
while @@FETCH_STATUS=0
begin
     INSERT INTO ....
 
      INSERT INTO ....
 
    fetch next from row_cursor into @ADRCONTACTINTITULE,@ADRCONTACTNOM,@ADRCONTACTPRENOM,@ADRCONTACTFONCTION,@ORGANISME,@ADR1,@ADR2,@ADRCP,@ADRVILLE,@ADRTEL,@ADRFAX,@ADRMAIL
end
close row_cursor
deallocate row_cursor

Lorsque j'execute ce code sur le serveur, un systemOutOfMemory apparait sur la fin du traitement.
Les insert into réalisés dans la boucle font appels à des triggers qui eux-même font des insert. L'erreur ne se produit pas sur tous les serveurs (seulement ceux ayant une configuration mémoire moindre)
J'en ai donc déduis qu'il s'agissait d'un problème de verrous mais je ne comprends pas comment cela peut se produire puisque le traitement est lancé lorsqu'il y a aucun accès concurrent.
Le code n'est il pas exécuté de manière purement séquentiel? Est il possible qu'une nouvelle itération de ma boucle commence avant même qu'un trigger déclenché par l'itération précédente est terminé son traitement?

Merci d'avance pour vos lumières.

[Drezounet218]

Avec l'utilisation d'un curseur, tu as N instruction insert, donc N appel aux triggers.

Dans cette configuration, je te conseille de désactiver les triggers le temps de l'import et relancer a "mano" les traitements effectué par les triggers
(attention, ceci n'est possible que si tu fais ton import en dehors de la période de production, car la désactivation des triggers concernera tout le monde !)

Sinon, une autre solution consisterai a supprimer le curseur que tu as et de modifier la requete afin de faire qu'un seul gros Insert ( ou 2 dans ton cas visiblement)
ce qui permet d'avoir qu'un seul appel aux triggers de la table concernée, cela peut améliorer grandement les perfs si il y a beaucoup de triggers complexes.


Sans connaitre le contenu de ta boucle, difficile de dire si le traitement peut facilement se passer de curseur

[djseb182]

Merci pour votre réponse.
Malgrès cela, j'ai du mal à comprendre ce problème de mémoire.
les instructions sont faites les unes après les autres. Il n'y pas d'accès concurrent. Les ressources ne sont donc t-elles pas libérées au fur et à mesure?

[ikeabp]

Bonjour,

J'ai rencontré auparavant des pb de mémoires sur des traitements longs, je ne sais plus si le message était tout à fait le même mais pour y pallier au lieu d'afficher le résultat de la requête par grille, je passais par "Résultats dans du texte" au niveau des options de MS "Résultats de la requête"... peut être une piste ?

[SQLpro]

Merci pour votre réponse.
Malgrès cela, j'ai du mal à comprendre ce problème de mémoire.
les instructions sont faites les unes après les autres. Il n'y pas d'accès concurrent. Les ressources ne sont donc t-elles pas libérées au fur et à mesure?

Un batch = 1 seule transaction => empilement des mises à jour....
Donc, consommation mémoire !

De plus vous utilisez tout ce qu'il y a de pire au niveau consommation de ressources :
1) fonction OPEN...
2) curseur
3) déclencheurs
...

Un SGBDR est optimisé pour faire du code ensembliste ! Pas du ligne à ligne remodifiées par déclencheur et lues par une fonction itérative !

A +