Discussion :

[NicaeaCivitas]

Bonjour

je suis confronté a un problème très bizarre: j'ai une stored proc exécutée sur une DB A qui génère du script SQL d'insert de data des tables de la DB A, script qui ensuite est tourné sur une DB B, bref en gros ça copie de A vers B. Le fait que ce soit fait en 2 étapes est normal.

Le script généré est grosso modo sous la forme suivante :

allocation d'une variable avec le nom de la table 1
insert du record 1 de la table 1
insert du record 2 de la table 1
insert du record 3 de la table 1
....
insert du record n de la table 1

allocation d'une variable avec le nom de la table 2
insert du record 1 de la table 2
insert du record 2 de la table 2
insert du record 3 de la table 2
....
insert du record n de la table 2

etc...

le script est généré correctement sur ma base de test et de pre-prod.
En revanche sur ma base de prod (et uniquement sur celle-ci) le script est généré de la manière suivante:


allocation d'une variable avec le nom de la table 1
insert du record 1 de la table 1
insert du record 2 de la table 1
insert du record 3 de la table 1
....
insert du record n de la table 1


insert du record 1 de la table 2
insert du record 2 de la table 2
allocation d'une variable avec le nom de la table 2
insert du record 3 de la table 2
....
insert du record n de la table 2

etc...

donc un bout de script est généré au mauvais endroit. De plus, le mauvais endroit n'est jamais le même, et il se peut aussi que ça se produise a 2 endroits différents dans le même script.

Les stored procs utilisées sont bien évidemment les mêmes sur ma base de test et de prod, tout est identique, sauf le serveur.
Donc je me posais la question si cela pouvait venir d'un problème de fuite ou d'allocation mémoire sur le serveur de prod, ou d'un quelconque problème lie a la mémoire ?
Ou autre chose ? J'avoue que la je sèche, ça fait + de 24h que je cherche sans trouver. Le plus chiant est de ne pas réussir a reproduire l'erreur.

[SQLpro]

Tout dépend du script, mais je parierait sur le fait que ton script se base sur un ordre hypothétique des lignes de table, alors que ce concept n'existe pas du fait de la nature ensembliste du SQL...
Et par exemple, si la requête de génération fait du parallélisme (ce qui est le cas si le volume à traiter est important), les lignes seront mélangées....
Il y a bien entendu d'autres cas possible....

A +