[T-SQL] Procédure & Mémoire [Résolu]

[JmL40]

Bonjour,

J'ai développé à l'aide de différents tutos. un script T-SQL que je souhaiterai mettre en place sous forme de procédure. Ce script doit permettre de mettre à jour une table d'une base de données si les conditions sont respectées.

Ma préoccupation est en fait au niveau de la gestion mémoire lors de l'exécution de ce script. En effet, après exécution la mémoire n'est pas libérée, et lorsque je ré-exécute la quantité de mémoire utilisée ne cesse d'augmenter.

Je pense qu'il doit y avoir des optimisations considérable à mettre en place dans mon script qui est vraiment, et je le dis du "bricolage". Voici une brève description de ce que je souhaite faire dans ce script :

1 - Extraction d'un compteur de lignes sauvegardé dans une table : @COUNTER
2 - Extraction du nombre de lignes total d'une vue : @VIEW
3 - Si @VIEW > @COUNTER alors je lance la suite de mon script
4 - Créations d'autant de fichiers qu'il y a de type (colonne :TYPE_STOCK) à partir de la vue et de la commande BCP.
5 - Pour chaque combinaison de type : XX, XY, YY, je lance un script PHP en SHELL qui va générer un fichier résultat dans un dossier.
6 - J'insère pour chaques fichiers XX, XY dans une table avec BULK INSERT.

Je présente ensuite mon script, sachant qu'avant exécution je suis a 700 Mo d'utilisation de mémoire et après, je suis a 1.20G et cette mémoire ne se libère pas. Je suis persuadé qu'il a des libération ou des optimisations.

Cordialement

[7gyY9w1ZY6ySRgPeaefZ]

Envoyé par JmL40

Je présente ensuite mon script, sachant qu'avant exécution je suis a 700 Mo d'utilisation de mémoire et après, je suis a 1.20G et cette mémoire ne se libère pas. Je suis persuadé qu'il a des libération ou des optimisations.

Par principe, la base de données ne rend jamais la RAM qu'elle utilise. Et vue qu'elle est sur un serveur dédié ça n'est pas un problème.

[iberserk]

Quelle mémoire?
Celle de votre Serveur SQL?

SQL SERVER ne libère la mémoire que si c'est nécessaire... vous n'avez pas (à votre niveau)à vous en soucier...

Je rappel que SQL SERVER doit être installé sur une instance dédiée.

[iberserk]

Par principe, la base de données ne rend jamais la RAM qu'elle utilise. Et vue qu'elle est sur un serveur dédié ça n'est pas un problème.

Je n'avais pas vu ton post :-) Pas sûr qu'il soit dédié ici

[JmL40]

Bonjour,

Merci pour vos réponses. Le serveur SQL est complété par un serveur Apache/PHP sur la machine.

J'essaye de trouver la meilleure optimisation pour mon script. Pourriez-vous visualiser si celui-ci ne contient pas des erreurs de scripting, d'algo. ou autres ?

Autre point, dans ce script je fais appel à du SHELL pour éxécuter un script PHP sur la même machine, et j'ai l'impression que cet appel ne fonctionne pas dans une procédure. Il fonctionne sous Management Studio. Mon idée est-elle possible dans une procédure ?

Exemple :

Code :

1
2
3
4
5
 
	DECLARE @DISTANCE VARCHAR(100);
	SET @DISTANCE = 'PHP d:\Roots\distance\distance.php ' + @FILE + '.txt install '
	SET @DISTANCE =  'EXEC XP_CMDSHELL ' + '''' + @DISTANCE + ''''
	EXEC (@DISTANCE)

Je précise que tout ce script est contenu dans une procédure.

Cordialement

[aieeeuuuuu]

Bonjour

Le serveur SQL est complété par un serveur Apache/PHP sur la machine.

Ceci est déconseillé. Si vous le pouvez, SQL Server doit etre installé sur une machine dédiée.
---

Je ne comprend pas très bien le principe de votre script, vous imbriquez les EXEC et xp_cmdshell ?

pour xp_cmdshell la doc est ici
Vous pouvez donc faire directement

Code SQL :

1
2
 
xp_cmdshell 'PHP d:\Roots\distance\distance.php ' + @FILE + '.txt install '

Cela dit :
1/ xp_cmdshell est désactivée par défaut, pour des raisons de sécurité
2/ Je vous conseille de faire autrement (pour les mêmes raisons de sécurité). Par exemple, sur votre (nouveau ) serveur php, lancez un script php qui récupérera le(s) nom(s) de fichier, et exécutera votre commande depuis PHP.

[iberserk]

Le serveur SQL est complété

"Complété" j'aime

[aieeeuuuuu]

Pour ce qui est de l'optimisation de votre script :
1/ pourquoi déclarer @COUNTER et @VIEW en VARCHAR(10) Alors que visiblement ils contiennent des nombres ?

2/ dans votre première requête, pourquoi utiliser IN (qui permet vérifier l'égalité d'une valeur avec une liste de valeur) alors que par définition, vous sous requête (dans le IN) ne peux renvoyer q'une seule valeur (vous faites un select MAX(...) )

donc je dirai :

Code SQL :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
DECLARE @COUNTER AS INT
SELECT @COUNTER = VALUE
FROM [COUNTER] 
WHERE [COUNTER] = 'CPT001' 
AND DATE_COUNTER = 
    SELECT MAX(DATE_COUNTER) 
    FROM [COUNTER] 
    WHERE [COUNTER] = 'CPT001' 
 
-- Récupération du nombre de lignes dans la vue VIEW_LAB_ANALYSE
DECLARE @VIEW AS INT
SELECT @VIEW  = COUNT(*) 
FROM VIEW_LAB_ANALYSE

Mais bon globalement cela ne changera pas grand chose...

J'ai même l'impression que vous vous servez de ces variables uniquement pour la comparaison, vous pourriez comparer directement les deux requêtes sans passer par des variables.


pour le reste du script, comme je vous disais, le mieux serait de récupérer la liste des fichiers à traiter, et de lancer ces traitements depuis un script PHP.

[JmL40]

Merci pour votre réponse ...

Je vais m'orienter vers la gestion des fichiers dans le script PHP.

En fait, je crois que je me suis compliqué dans la gestion des différents traitement au niveau SQL et PHP. Je peux très bien créer les fichiers sources par la commande BCP dans mon script PHP, de même pour les fichiers résultats, en allant chercher les différents fichiers résultats à générer.

Par contre simple question :

Code :

xp_cmdshell 'PHP d:\Roots\distance\distance.php ' + @FILE + '.txt install '

Ne marche pas dans une procédure, le script ne s'exécute pas ...

[aieeeuuuuu]

Envoyé par JmL40

En fait, je crois que je me suis compliqué...

Je pense aussi

Par contre simple question :

Code :

xp_cmdshell 'PHP d:\Roots\distance\distance.php ' + @FILE + '.txt install '

Ne marche pas dans une procédure, le script ne s'exécute pas ...

Il faut :
1/ autoriser l'utilisation de xp_cmdshell
2/ donner a votre utilisateur SQL le privilege d'execution de xp_cmdshell (GRANT EXECUTE...)
3/ donner les droit à l'utilisateur windows pour l'execution de votre commande (le compte du service MSSQL je crois ?)

Une fois que vous aurez trifouillé pour effectuer cela, vous aurez ouvert des trous, que dis-je des trous... des cratères de sécurité...

non vraiment, laissez à votre serveur de base de données le soin de s'occuper des données, et à votre langage de scripting le soin de s'occuper du reste...

[JmL40]

OK

Je me ré-oriente vers la gestion des fichiers de données dans mon script.

La sécurité n'a pas de prix !

Cordialement

PS : je met le TOPIC en résolu !