[TSQL] Rapidité d'exécution lors d'une migration de données d'une base à une autre

Bonjour à tous!

Que je vous explique mon problème...

Mon travail actuel consiste en la migration de données (données de production et de configuration d'un logiciel) d'une base SQL Server 2005 'A' vers une autre base SQL Server 'B'.

Bien que la fonction première de ces deux bases est sensiblement la même, leur modèle de données est vraiment très différent.

Pour ce faire, j'ai développé des scripts SQL, etj'utilise des curseurs... Oui oui, j'assume.
Avant de crier au scandale, je vous assure que j'ai bien étudié la chose, et au vu de la complexité de cette migration, c'est vraiment le choix qui s'impose... Promis.

Bref, revennons-en à nos moutons:

Lors de la migration de tables de production assez importantes (+ de deux millions de lignes), par l'intermediaire d'un curseur sur ma table "source" (base A), l'exécution est très très lente (environ 5000 lignes minutes!).

J'ai tout tenté (test en charge de différentes requêtes, sous-requêtes, tables temporaires, etc..).

Je me suis aperçu qu'en ouvrant (clic droit, "ouvrir la table") ma table "source" sous la base A depuis le Management Studio Express pendant l'exécution de mon script, je passe à plus 150 000 lignes minute...

Je ne vois pas trop d'où viens cette différence. Pour moi c'est incompréhensible.

Autres infos:
J'utilise SLQ Server 2005 Express, sur un ordinateur récent.
Après défragmentation, la chose s'améliore un peu, mais pas de trop.

Si vous avez des idées sur le pourquoi du comment, je suis preneur :D

Merci d'avance.
Pillou

Citation:

---

Envoyé par pillou

Pour ce faire, j'ai développé des scripts SQL, etj'utilise des curseurs... Oui oui, j'assume.

---

Assume jusqu'au bout alors... Les problèmes de performances liés aux curseurs ne sont pas nouveaux ;)


Pour la différence de vitesse que tu observes une fois que tu as ouvert ta table A peut provenir du fait que tu charges la mémoire (cache) avec les données de ta table A et que tu accèdes à celles-ci directement en mémoire plutot que d'aller lire ligne par ligne sur le disque.

Merci pour ta réponse Ptit_Dje.

Je pense aussi que c'est une question de chargement de la table source en mémoire... d'ailleur quand la table est "ouverte", je n'entend plus les petits bruits caractéristiques des accés disque :).
Maintenant je ne vois pas comment intégrer la chose directement depuis mon script SQL (ou en configurant la base et/ou le serveur?).

Si quelqu'un à une info...

Merci d'avance.

Pour integrer une ouverture de la table... Utilise un select * de ta table dans ton script avant de démarrer avec le curseur.

Bien que je te conseillerai d'utiliser des loops pour remplacer tes curseurs, surtout sur d'aussi des tables aussi grosse.

Pour faire du row par row tu peux utiliser un truc du genre :

Code:

---

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

declare @i int declare @maxId int   create #loopTable ( idLoop int identity (1,1), col1, Col2, ... )   insert into #loopTable (col1, col2 ....) select col1, col2 .... from tableSource where filtre   --- Tu peux meme penser à creer des index sur ta table temporaire ici   set @i = 1 select @maxID = max(idLoop) from #loopTable   while @i <= @maxId begin select .... from #loopTable where idLoop = @i   .........   @i = @i + 1 end

---

Merci pour ton aide Ptit_Dje, mais le select * sur les tables "sources" avant traitement ne change rien...

Merci aussi pour l'info sur les loops, mais crois moi je ne pense pas avoir vraiment le choix quant à l'utilisation des curseurs :oops:

C'est vraiment une histoire d'accès disque, vue que ni le processeur et la ram ne sont en surcharge pendant le processus... et de loin.

Personne n'a eu ce gene de problème?

Merci d'avance.

EDIT: idem quand j'ouvre la fenêtre propriété de ma table source... le processus s'accélère :roll:
EDIT 2 : Dans ces deux cas (ouverture et propriétés sur ma table "source") l'utilisation de mon UC gonfle et reste stable à environ 20%. Dans le cas contraire: variation rapides de 2 à 13%. Juste pour infos.