Discussion :

[Arnard]

Bonjour,

je veux migrer des données d'une table X dans une base I sur un serveur A vers une table X dans des bases I et J sur un serveur B.

A.I.X ==> B.I.X et B.J.X

Les tables ont le même schéma.

Le traitement de migration est effectué régulièrement via un job.

La procédure est écrite en C#.

1. J'ai un problème de timeout sur l'envoi d'un simple insert, il lance la commande et au bout de 30 secondes, time out. Comment puis-je savoir pourquoi il fait ça ? Si je fais la requete en dur sur management studio sur le serveur A en me connectant au serveur B, je n'ai pas ce problème. Pourquoi ai-je ce timeout, comment en trouver l'origine ?

2. Les choix d'architectures sont-ils bons ?

Merci

[Philippe Vialatte]

Salut,

1. J'ai un problème de timeout sur l'envoi d'un simple insert, il lance la commande et au bout de 30 secondes, time out. Comment puis-je savoir pourquoi il fait ça ? Si je fais la requete en dur sur management studio sur le serveur A en me connectant au serveur B, je n'ai pas ce problème. Pourquoi ai-je ce timeout, comment en trouver l'origine ?

Si tu te connectes par management studio, combien de temps la requete tourne t'elle ? Si elle tourne 31 secondes, il faut peut-etre modifier ton timeout au niveau de ton appli de migration

2. Les choix d'architectures sont-ils bons ?

Euh...quels choix d'architecture ?
De copier des donnees sur un serveur ?

Il manque trop de contexte pour pouvoir die quoi que ce soit, quelles sont les quantites, les contraintes & co.

[Arnard]

Bonjour,

pour le souci de timeout, j'ai redémarré le service sql server et ça a résolu le souci. Mais une deuxième procédure se retrouve dans le même cas, et redémarrer n'y change rien... C'est la première requête d'insertion qui pose souci, elle ne contient qu'une trentaine de champs, mais par contre la table de destination contient déjà plusieurs centaines de milliers de lignes. En local l'insertion est instantanée.

Par contre en local une requête select count(*) sur la table de destination arrive à prendre 5-10mn, ce qui me semble aberrant...

Pour l'architecture, il s'agit de copier toutes les minutes X lignes, allant de 0 à 1000 dans l'idée.

[Philippe Vialatte]

Par contre en local une requête select count(*) sur la table de destination arrive à prendre 5-10mn, ce qui me semble aberrant...

Ca sent un probleme au niveau de la base de donnees, ca...quand tu fais une requete distante, si tu as la main sur le serveur distant, qu'est-ce qu'il dit (charge cpu, memoire...) ?

Est-ce que c'est une table "normale", ou une vue ?

Pour l'architecture, il s'agit de copier toutes les minutes X lignes, allant de 0 à 1000 dans l'idée.

Ce ne serait pas plus simple si la structure de table est la même, d'utiliser des fonctionnalités de log shipping ? ou de replication/mirroring ?

[Arnard]

Il s'agit d'une table normale.
Je fais des requêtes sur d'autres tables qui contiennent 30 000 lignes avec un résultat automatique, par contre les count(*) sur mes fameuses tables mènent maintenant à une fermeture du canal avant d'avoir le résultat...

Faut-il paramétrer les tables pour manipuler de gros jeux de données ?

J'ai regardé vite fait le log shipping, et cela ne me convient pas, car je désire supprimer les données du serveur A quand je les copie sur le serveur B

Merci de ton aide en tout cas pour ce souci de table -_-

[Arnard]

J'ai fait un soft console pour tester l'insertion à distance, ça roule sans souci et en un clin d'œil...

J'ai ouvert un thread sur la durée anormale des count(*)

http://www.developpez.net/forums/f49...ms-sql-server/

[Arnard]

Bon apparemment ces time out étaient du à des select(*) en parallèle, select verrouillant la table, empêchant de lire les données. Sans verrou ça roule

Merci